On Thu, Jan 19, 2017 at 5:49 PM, Jacob Champion <champio...@gmail.com> wrote: > This is somewhat orthogonal to Bill's current suggestion. It solves a > different set of problems, more related to the short-term > features-versus-regressions argument and less related to the long-term ABI > arguments. Both are important to me, and I agree with many pieces of what > both Jim and Bill are saying. > > (This is a combination of a bunch of different ideas from different people, > on this list and off, so thank you all for discussing.) > > == Proposal == > > 2.4.25.x is on a cadence: it's T&R'd like clockwork every month. Releases > from that line still follow the necessary voting procedure. Meanwhile, once > we decide we have enough new features for 2.4.26, we T&R that. If 2.4.26 > releases, and we decide we need some fixes, we spin up a 2.4.26.x branch and > move to a cadence on it.
This is the OpenSSL model which httpd effectively mirrors today, although their .x is an alpha sequence, and your proposal could be read with either semantic. However, OpenSSL changes very little in terms of it's scope, and isn't the best model for an evolutionary, development driven project like httpd. 1.0.0 and 1.1.0 both refactored much of the API in terms of opacity of internal data members. 1.0.0, 1.0.1, 1.0.2 were incremental TLS features, but as these were defined by spec, the scope of those upgrades was clear. So I'd anticipate 1.1.1 if the API is extended further for new TLS features without other changes, or I'd anticipate 1.2.0 if the API will be further refactored (or both.) But given the amount of recoding required to migrate from 1.0.x -> 1.1.0, as illustrated by a bunch of patches here for mod_ssl, most modern developers would have considered that rework a 2.0 scope change. At least the OpenSSL project accomplishes what you outlined above, irrespective of their number-alpha'ing schema.
