On Fri, Jan 20, 2017 at 4:04 AM, Graham Leggett <minf...@sharp.fm> wrote:
> On 19 Jan 2017, at 11:43 PM, William A Rowe Jr <wr...@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.
>
> 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.
I do. Remember that the version numbering elected for 2.0 was based on
the direct and recent experience of 1.2.x and 1.3.x. There was no API
or ABI assurance throughout 1.2.x until 1.3.12-1.3.14 time frame
(which became the ABI final 1.3.x representation). Third party
modules would have to be rebuilt, and sometimes patched, between
subversion releases.
Understanding that context is necessary to understand why 2.0
numbering was adopted. Floating ABIs during 2.{odd} releases, fixed
ABIs during 2.{even} releases balanced the desires for a messy
development phase and a stable maintenance phase. When you look at
early (2.0.0 - 2.0.36) development as an initial {odd} Floating
ABI/API period, it makes sense.
>> 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.
>
> -1 (veto).
To be clear, procedural decisions can't be vetoed. But specific code
changes can be vetoed.
I can veto and revert each individual commit on trunk which breaks the
API or ABI in an unnecessary manner, pointing at that specific
breakage, and invite the committer to propose the change using the
existing interfaces. Even if that commit dates back soon after the
2011 fork. Where the code is accepted in 2.4.x, I can offer the
author's own 2.4.x backport commit to align their work in an API
stable manner to what is shipping and finally trusted. If it was good
enough to ship in 2.4, there better be an awfully good reason for a
code divergence. In almost every case, it was a sloppy trunk/ commit
and some careful thought applied to how to introduce it into 2.4.x.
And no, you can't then veto such specific vetos. The window to veto
code is before the ASF releases the code.
For forward-ports, you would look awfully silly vetoing a patch
accepted in 2.4.x.
In light of your objection, I won't proceed with a preservation
branch, but take the veto knife directly to trunk.
> 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.
There is nothing in httpd which is stable, and 2.4.x certainly hasn't
been well established. Not even 50% of Apache httpd deployments use
2.4.x almost four years later, and 2.4.25 looks so considerably
different than 2.4.1 that it cannot be called a maintenance branch. It
is impossible to identify from "2.4" what point in its evolution is
causing a reported issue without knowing the subversion. A handful of
2.4.x releases walked out the door without some significant regression
- not a proud track record. So this problem which I'm trying to solve
is clearly present.
The second inherent problem you sum up below also certainly exists;
> 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.
Not releasing their contributions puts the project at risk of having
contributors walk away from offering further contributions. That was
well established in earlier threads this past month, and originates
from a pattern where trunk/ is not released. My goal is simply a
better user experience trusting they can make subversion upgrades with
no disruption (which has not been possible throughout 2.4.x), also
trusting frequent minor version upgrades to deliver new features, and
treating all significant disruption as major version releases. As one
example. the auth directive block-scope changes were significantly
disruptive to reserve such changes for a major version release.
I'm open to multiple ideas to accomplish how this goal would be
numbered / realized, and different ideas of how we partition space at
httpd for disruption, enhancement and growth existing versus and
alongside a stable consumer experience between releases (hopefully
more frequent than twice a decade.) I'd be very interested in hearing
proposals from those who have argued most vehemently for the
enhancement case before bringing this to a proposal that will satisfy
80% of the committers and carve out space for all committers to
participate.
Finally the fact that httpd's last release was Feb '12 indicates to me
a project at risk.
