4.0.0 release

[neo22s]

Release and branching plan (thanks to @enov)

• [x] Release 3.3.5
• [ ] Review and restructure outstanding Github issues and PRs
  • Restructure milestones, rename 3.4 milestone to 4.0
  • Review and close all issues and PRs that are no more relevant
  • closing any that are redundant, out of date or not of high enough quality to merge
  • merging any bugfixes that are backwards compatible so that they can be in 3.3 and 4.0
  • merging any breaking changes that are close enough to complete to go with the upcoming breaking 4.0 release
  • assigning any longer-term breaking changes (including issues that nobody's started working on yet) to a new 5.0 milestone
• [ ] Merge 3.3/develop to 3.4/develop
• [ ] Create a master branch based on 3.4/develop
• [ ] Delete all 3.*/develop branches
• [ ] Delete all other unwanted branches
• [ ] In the master branch fix all occurrence of 3.4 with 4.0
• [ ] Fix composer required versions in master
• [ ] Update kohana/koharness script for new branch naming structure
• [ ] Update Travis scripts to make the tests pass
• [ ] Write new CONTRIBUTING guidelines reflecting branching changes
• [ ] Do above steps for all Kohana modules
• [ ] Create a 4.0.x branch based on the master branch
• [ ] Review changes and write/update changelog and upgrade guide
• [ ] Change the version and the codename on a separate commit in that branch
• [ ] Release by tagging v4.0.0-beta1
• [ ] Update kohana-ci scripts for new branch naming structure (optional)
• [ ] Do above steps for Kohana modules that have BC braking changes, no need to newly release those who are not changed

From https://github.com/kohana/core/issues/660

[neo22s]

Ok, I have done what I could:

• created 5.0.0 milestone, moved many issues there that are just ideas.
• reviewed all issues on core move them or closed them (please review)
• reviewed all PRs on core and close those are old and not merged.

[svenbw]

I notice that nothing happens on any of the modules. To complete the release and branching plan above the modules should also clean up obsolete PR's and accept the ones that are valid.

[neo22s]

we should draw a list of what will be new for 4.0.0 besides PHP7 support and PSR-3 compliance are we3 planning anything really big? I will not ;)

[acoulton]

@neo22s good point I've added writing/updating changelog and update guide to the release plan above. Probably the best starting point is to review the git commits between the 3.3 and 4.0 branches (on all modules) and make sure everything is documented.

[neo22s]

@acoulton the thing is that I am bit lost right now truth to be told.

So we should compare all modules the difference between 3.3 and 3.4 and add them to 4.0. and document it?

Also a migration guide? thats like the most important xD Seems that due to psr3 compliance the migration will be quite painful.

[enov]

There is already a migration guide. PSR-3 compliance notes are there, well documented.

[enov]

Needless to say, there might be some changes not documented. As @acoulton suggested, it would be good to review git commits on all modules.

[acoulton]

@neo22s yes - each module, and core, needs to be compared and then add anything relevant to the upgrade guide that @enov has already produced for the PSR-3 changes.

Possibly with this release we should start to keep a proper short CHANGELOG in the root of each composer repo?

[svenbw]

If the changes are big a "short" changelog might not be sufficient. A markdown document as the PSR-3 compliance of Kohana logger take more time but gives a good and clear overview of the changes and actions to do a proper migration. It might be a good idea to add a document for each functionality (Log, Request, URL, Route, ...) this should give an easy way to find and solve migration issues (assert on route call, look in the route document).

[acoulton]

@svenbw, of course, it's not an either/or. The short changelog acts as a summary and overview of everything and links to the more detailed docs for big changes.

Off the top of my head I don't think there are many big changes so far apart from PSR-3 which @enov has documented very thoroughly. Until someone does a compare and writes the short changelog, we won't know...

[Azuka]

@neo22s, I've been following this for a while. What's the status of the tasks in your list and how can we help?

[neo22s]

hello @Azuka this is dead.... me an few others have forked it https://koseven.ga/

[Azuka]

Oh, thanks. I'll post in the other repo.

[neo22s]

thanks to you!

[acoulton]

@neo22s sorry to hear it's been forked... was there a reason for that other than lack of progress here? AFAIK the only reason Kohana's 'dead' is that none of us have had a chance to get this release out. If you and others are going to spend time on it, wouldn't it make sense to do that here (where you have commit access)?

[neo22s]

We needed 3.3.X branch to be alive since we can not migrate huge projects or we dont have the budget. many people has contacted me during this month's interested on keeping at least updated the core, compatible with PHP7 not adding new features but yes fixing bugs. As you say things are not happening here, its not clear who makes decisions things get forgotten or never checked often... I have tried many times without success to keep kohana alive. I did the fork long ago to make it compatible for PHP7 and since then many people has contacted me privately , now theres on telegram at least 8 active members who are willing to collaborate with good faith, hope we can keep it like this.

If anyone is interested to join please feel free, you are more than welcome, no matter which role or your skills. I am putting resources in any means, as I proposed before for Kohana.

Thanks.