httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: Alternate versioning proposal: patch line releases
Date Fri, 20 Jan 2017 14:59:55 GMT
On Thu, Jan 19, 2017 at 5:49 PM, Jacob Champion <champion.p@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.

Mime
View raw message