On Tue, Mar 31, 2015 at 9:44 PM, Rowan Collins <rowan.coll...@gmail.com> wrote:
> 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? > +1
