httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: Reset out x.minor.z definition of 'minor' at httpd?
Date Fri, 20 Jan 2017 09:09:26 GMT

> Am 20.01.2017 um 01:46 schrieb Eric Covener <covener@gmail.com>:
> 
> On Thu, Jan 19, 2017 at 4:43 PM, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
>> I think one of our disconnects with 2.4 -> 2.6 is that in any other
>> framework, there would be no ABI breakage in 2.6. That breakage
>> would be deferred to and shipped as 3.0.
>> 
>> The httpd project choose to call 2.minor releases as breaking
>> changes. Due to poor design choices, or frequent refactorings,
>> this essentially shifted our release numbering schema down one
>> digit. So 2.6.0 is not an enhancement release, but a major release
>> in the general understanding of these things. This might be the root
>> of Jim's and my failure to come to any consensus.
>> 
>> Right now, there are a number of gratuitous breaking changes on trunk
>> that change binary ABI. I'm considering a trunk fork to preserve these
>> changes (branches/3.x-future/?) and reverting every change to trunk/
>> which was otherwise a no-op. Namespace, decoration, anything that
>> prevents a user from loading a 2.4.x module in 2.next. And then we
>> can look at what is a valid reason to take us to 3.0.
> 
> The  "why" missing here is presumably to allow a 2.6 to be cut from
> trunk. But in that case, why not just fork it from 2.4 w/o a major nor
> magic cookie bump and let 2.4 become the more conservative stream?

+1

Just some brainstorming:

LTS/Stable/Feature branches

2.2.x/2.4.x/2.6.x    for now
2.2.x/2.6.x/2.8.x    if we think new features in 2.6 are stable and want to add more features
2.4.x/2.4.x/2.6.x    if we end LTS for 2.2, the new LTS can be a stable branch
2.2.x/2.4.x/2.8.x    in extreme cases, we could ditch a feature branch and move on.

- we continue working in trunk
- backports to LTS/stable branches as now, review then commit
- backports to feature branches: commit, then review
- LTS is the support promise, stable/feature can move more freely
- Feature is completely "experimental", we make no promises
- Distros can support stable longer than we do, which is basically the model they are doing
now for their LTS.
- people will argue for more than 1 LTS release, but I think that is too much for the project,
more something for a commercial undertaking

(and there could be odd version numbers in there as well, but does not matter to me)

> [...]

Stefan Eissing

<green/>bytes GmbH
Hafenstrasse 16
48155 M√ľnster
www.greenbytes.de


Mime
View raw message