2010/11/23 Ilia Alshanetsky <i...@prohost.org> > I think support 5 or even 3 parallel versions will be highly > impractical and extra-ordinarily challenging. I think we need a plan > that limits us to 2 versions and perhaps a 3rd one for critical > security fixes only. > > 2010/11/23 Johannes Schlüter <johan...@schlueters.de>: > > Hi, > > > > On Mon, 2010-11-22 at 23:21 -0200, Felipe Pena wrote: > >> With the recent chaos in the way we begin and ended releases, we would > >> like to propose a clean way to deal with releases and related decisions: > [1] > > > > Thanks for preparing this. I have one change proposal: > > > > With the proposed model it might, as you have illustrated, happen that > > there are 5 versions being maintained. > > > > As I mentioned multiple times on this list, on irc and other places I > > like a Ubuntu-like model with two kinds of release which I, for the > > purpose of this discussion, call "early access" (EA) and "long term > > supported" (LTS) version. > > > > At any given time only one EA may exist. When a new LTS version is being > > released the previous LTS version enters security-only mode to give > > users a transition period. Between every LTS version there are two EA > > versions. > > > > 2011 2012 2013 2014 2015 2016 > 2017 > > | | | | | | | | | | | > | | > > LTS1 +++++++++++++++++++++++++++++++++++++-----------D | | > | | > > EA1 | | ++++++++++++D | | | | | | > | | > > EA2 | | | | ++++++++++++D | | | | > | | > > LTS2 | | | | | | > ++++++++++++++++++++++++++++++++++++-----------D > > EA3 | | | | | | | | ++++++++++++D > > EA4 | | | | | | | | | | > ++++++++++++D > > > > The benefit is that developers and users who require a specific feature > > get it early while distributors/hosters/software vendors/... have a safe > > bet. > > > > johannes > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > You can't expect the users to switch to the new major version as soon as it comes out. They have to either migrate their codebase, and sadly they will wait(at least me and my collegues/friends do this) one or two micro/build version bump, usually the new major/major.minor version is stable enough.
So if we want to support "equally" 2 major version concurrently, I can't see how can we make it through supporting 4 branches (oldmajor.last, oldmajor.current, newmajor.last, newmajor.current) or we can make "unequal" or "favored" branches: - either an early adopter vs lts sytem like ubuntu does, but they have 4 supported version at a time also https://wiki.ubuntu.com/LTS but I don't know how to mix LTS and php, because they release "shared nothing" versions, while the php versions does share a common codebase through their major version, so we can't plan beforehand that what version will be the nextlts before getting there like the ubuntu guys can. :/ - or stopping the development on the oldmajor version (I mean no new minor version for the oldmajor, only micro/build bugfix releases) with that modification, the multiple major version would be like this: http://wiki.php.net/rfc/releaseprocessalternatives what do you think? Tyrael
