httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: Reset out x.minor.z definition of 'minor' at httpd?
Date Fri, 20 Jan 2017 10:04:10 GMT
On 19 Jan 2017, at 11:43 PM, William A Rowe Jr <> 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.

I don’t see any relationship between poor design choices / frequent refactorings and a decision
made in the late 1990s on a version numbering system.

> 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 And then we
> can look at what is a valid reason to take us to 3.0.

-1 (veto).

As you are well aware, the jump from v2.0 to v2.2, from v2.2 to v2.4, and the jump from v2.4
to v2.6 involves breaking changes, and this is a well established and stable pattern that
is well understood by our end users. The “problem” you’re trying to solve does not exist.

Arbitrarily reverting the work of others displays a profound lack of respect for those members,
committers and contributors to the ASF who have contributed to our codebase. This behaviour
discourages collaboration between the community and project, and puts this project at risk.


View raw message