On 31 March 2015 21:09:47 GMT+01:00, Stanislav Malyshev <smalys...@gmail.com> wrote: >> This is a straw man as far as the points I made are concerned. I'm >> talking about the risk of switching from 5.5 to 5.6, which is pretty >low. > >Switching to 5.6 would be useless since what is being propose it to ban >any enhancements up to 7.1.
Proposed by whom? The only mentions of 7.1 I've spotted have been from you, which is why I called it a straw man. So, rather than arguing round in circles, here's what I would propose: - Up until the first release candidate of x.y.0, small features can be added to both the most recent live branch and the new branch being prepared for release (so, right now, 5.6.x and 7.0-pre; next summer, 7.0.x and 7.1-pre). - Once a new x.y.0 release is ready, x.y-1.z releases should receive bug fixes only. Thus 5.5.x should not be receiving features. - As an exception to the above, when releasing x.0.0, the previous branch may continue receiving small features, until it reaches the end of its "active support" phase. In other words, keep backporting things to 5.6.x after 7.0.0 is released, since adoption of the latter is likely to be slow. By the time 7.1.0 comes around, active support for 5.6 will have ended anyway, unless we make some other exception to the normal process. This is very much a compromise between the SemVer ideal of a patch release, and the practical implications of a yearly release cycle. The aim is to make it obvious to users what they'll get in return for upgrading, and to smoothly transition a branch from "cutting edge" to "stable with bug fixes", then to "security only" and "end of life". What do people think? Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
