Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

4.0.0 release #672

Open
1 of 18 tasks
neo22s opened this issue Mar 21, 2016 · 16 comments
Open
1 of 18 tasks

4.0.0 release #672

neo22s opened this issue Mar 21, 2016 · 16 comments

Comments

@neo22s
Copy link
Member

neo22s commented Mar 21, 2016

Release and branching plan (thanks to @enov)
  • 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 #660

@neo22s neo22s added this to the 4.0.0 milestone Mar 21, 2016
@neo22s neo22s mentioned this issue Mar 21, 2016
17 tasks
@neo22s
Copy link
Member Author

neo22s commented Mar 21, 2016

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
Copy link

svenbw commented Mar 22, 2016

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
Copy link
Member Author

neo22s commented Mar 25, 2016

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
Copy link
Member

@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
Copy link
Member Author

neo22s commented Mar 25, 2016

@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
Copy link
Contributor

enov commented Mar 25, 2016

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

@enov
Copy link
Contributor

enov commented Mar 25, 2016

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
Copy link
Member

@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
Copy link

svenbw commented Mar 25, 2016

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
Copy link
Member

@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
Copy link

Azuka commented Jan 27, 2017

@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
Copy link
Member Author

neo22s commented Jan 27, 2017

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

@Azuka
Copy link

Azuka commented Jan 27, 2017

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

@neo22s
Copy link
Member Author

neo22s commented Jan 27, 2017

thanks to you!

@acoulton
Copy link
Member

@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
Copy link
Member Author

neo22s commented Jan 27, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants