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.