Am 31.03.2015 22:45 schrieb "Rowan Collins" <rowan.coll...@gmail.com>: > > - 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?
That sounds very reasonable, and would suit me fine :) One issue that I think speaks for such an approach, is giving new-small-features better exposure outside of developer circles. If features only ever go into the-next-tree, they won't be seen and tried out in the field until after that is committed as a new-stable release. The feature also probably can't be added to the php.net documentation until that release happens (right). Lots less eyes seeing it, finding problems with it that might be rectified before next-becomes-stable. I think there's a three layer hierarchy of adoption at play here, which also can explain the low adoption figures of newest-stable. At the top, you have next-stable, which will be visible almost exclusively to contributors, and won't get any real world production exposure at all. Then you have the current stable, which is used by shops (like mine...) that care about building their own binaries, and that have a rather homogenous inhouse codebase that can evolve to use new major and minor features in production. And then there's the vast field which runs on distribution builds, which seems to sit on the oldest supported stable version in existence until it's faded out, and which doesn't care about new features at all. Do I make sense? :) best regards Patrick
