Open Issues reported for version 3.3.2 in Redmine that were not fixed in version 3.3.3 about core

[enov]

4835 and 4833 are invalid.

[enov]

4836: added jpe file extension as IMAGETYPE_JPEG in kohana/image@c8d7dc4

[enov]

4806 might also be invalid. PDO uses no identifiers, it can be set by creating a new driver that extends PDO.

[enov]

4797 seems to me a request to add some undocumented installation glitches, related to Apache .htaccess, to the manual. There is a suggestion by @WinterSilence to enhance the RewriteRule, that might be worth looking at. However, I did not note anything pressing.

[enov]

@acoulton I believe all these open issues should be closed in Redmine.

[enov]

Can we say it's time to release? 🏄

[enov]

Is there a hope for a release?

[acoulton]

@enov sorry, I somehow didn't see your last post.

I say let's go for it, there's a lot of good changes come through.

Who's going to do it? You/me/@shadowhand?

[enov]

I guess @shadowhand should be around, in case something wrong happens, either you or me, it does not matter.

[enov]

Do you think we should delete 56e452c (git reset --hard)?

[enov]

so that we won't face a merge conflict once we create a release branch to change the codename and release version number.

[enov]

@acoulton I have started to locally merge develop braches of the modules to master right now, with a 3.3/release/3.3.3 branches in between.

I think it is easier to tag them after pushing, through Github interface.

Am I missing something?

[acoulton]

Yeah, I guess that will work. Presume you've updated the version number in kohana/core?

I wouldn't delete 56e452c as that commit reference will be in people's composer.lock and their composer install will suddenly start failing - which wouldn't make you popular!

I'd probably merge 3.3/master back into 3.3/develop and then start the release branch after that, then there's no merge conflict.

[enov]

I am done with the modules, I guess. I also pushed codebench module. Could you look if it is OK?

[acoulton]

@enov I need to head off, but seems like the merge to master in kohana/cache went wrong, the travis configuration is broken and badges have gone missing from the README.

[enov]

I was able to reset that. I will see how I can try again. I guess it happened because of a merge/revert directly in master.

[enov]

The only solution to this, as far as I can see, is to merge 3.3/master into 3.3/develop and replay the commits for kohana/cache#56?

[enov]

This seems to be helpful:
https://metlos.wordpress.com/2012/01/13/git-merging-after-a-revert/

[enov]

Released.

[acoulton]

@enov nice one, it looks like maybe you never pushed your unittest repo as the kohana/kohana build is broken - commit ref is not found.

[acoulton]

And also, the 3.3/master branches then all need to be merged back to 3.3/develop and also 3.4/develop

[rjd22]

This is for you guys: 🎉 @acoulton @enov

[enov]

Thanks @rjd22.

you never pushed your unittest repo as the kohana/kohana build is broken - commit ref is not found.

You're right @acoulton 👍 It's done now.

[acoulton]

@enov

[enov]

Haha! Thanks to you too, @acoulton, it would not have happened without you.

[enov]

And also, the 3.3/master branches then all need to be merged back to 3.3/develop and also 3.4/develop

Will take care of that, too.

[rakucmr]

Great job, thank you for all your efforts!
When will you publish also on Kohana website?

[enov]

Thanks @Raku! I just made a PR to the website kohana/kohanaframework.org#20.
Cheers!

[rakucmr]

@enov I want to rewrite Auth module to include new features like, login throttling, hash using password_compat, driver for using oauth and open id, password reset, user activation, should I make It compatible with current Auth version or start it from beginning?
What other features do you think it should contain?

[enov]

All those features you stated are important, but I am not entitled to take the decision and/or give you the green light. You need to open a new issue at https://github.com/kohana/auth and discuss things there. Also, it seems there is consensus to drop the auth module altogether in the future, because it seems it is a maintenance burden.

[rakucmr]

I've opened but was closed by the owner of the Kohana Framework :)
If we drop this, then ORM, then others modules, what will remain from this framework ... I think the idea of a framework is to offer more and more features, not to drop them.
If something is not good repair it until is good enough not just drop it.

[rjd22]

@Raku the goal is a minimum framework that handles requests and responses and use external libraries to solve issues other than that. Auth is a easy problem to solve but can also be a really hard one depending on what the requirements are. The PHP world is evolving and using external libraries is a breeze not thanks to composer.

Our reasons for dropping it is that there are others solving the problem way better than we ever would be able to do. Like https://github.com/cartalyst/sentry for solving normal auth, https://github.com/thephpleague for oauth and https://github.com/doctrine/doctrine2 for ORM. We could never solve all those problems better than they do now with the amount of people we have working on Kohana right now.

So it would be better to solve the problems we can like request and response and everything that is connected to that.

[rakucmr]

:) Here is the problem that you think it like a small framework.
I think you will find other solutions that makes things better than Kohana if you split it component by component. The power of a framework is in all of it's components together.

[acoulton]

@Raku a small framework means you're not tied to complex "catch-all" implementations, but can pick the right libraries for the right jobs. It also means you get the benefit of a much larger development team (each specialising in and working on the component they produce) rather than having to rely on a small group of people to implement the whole of Kohana.

If you think there's a need for a modern Kohana auth module you're of course welcome to write one and publish it - but I don't think you'll find any of the core team keen to work with you on making it an "official" kohana module. We're all fairly clear that this is a solved problem, and the only reason to keep kohana/auth dragging along is for legacy compatibility.

If a developer is going to have to learn and integrate with a new API anyway, they'd be better off choosing one of the third party solutions that already exist and work very well.