You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2017/01/19 21:43:23 UTC
Reset out x.minor.z definition of 'minor' at httpd?
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.
There might be some minor breakage that requires a recompilation,
such as a user module allocating a req_rec. That is solved by setting
a showstopper to the 2.next release to introduce _create() accessors
to every structure belonging to the httpd API. There would be side
determinations... would we institute such a change with the release
of 2.5, or 2.6, or 3.0?
Once this is complete, binary breaking ABI changes would live in
their own feature development forks. They would never be folded
into trunk until there was a group consensus to push forward to
version next.0.0 in the immediate future. trunk/ would cease to be
a sandbox of ideas unready for release.
It's likely a couple-week process that I can't start till the end of next
week. But I think the frustration about not being able to ship new
features has a lot to do with our history of breaking API's every time
we ticked up the version minor number.
It might be that we won't end up shipping 2.6 because other good
and necessary binary-breaking-changes occur between now and
in the near future, or that these exist on trunk. But if we defer the
gruntwork of renaming things and whitespace mop-up etc until
a short several-week period prior to the actual major.0.0 release,
then we can keep trunk/ in a much more releasable state for all
the new features.
We may have the impetus for a 3.0 release in the near future, we
may not, but I'm sure the idea that 2.5 is a 'major' ABI-breaking
release is not serving us well.
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Jan 19, 2017 at 6:05 PM, Jim Jagielski <ji...@apache.org> wrote:
> Bill 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.
>
> Huh? For just one single, simple example, what about APR??
Those are the rules of APR today.
httpd today compiles against either apr-1 or apr-2.
I don't understand your question?
> Are we going to now redefine the standards of semantic versioning??
Maybe this will help illustrate our conflicting perspectives on versioning;
w.m.n.x
I understand your interpretation as
w == wow factor (major breakage)
m = minor (also major breakage)
n = subversion (new features + enhancements, no breakage)
While I understand versioning as
m = major (major breakage)
n = minor (avoid breakage, new features + enhancements)
x = subversion (feature stable, bug + regression fixes only)
I understand you (and perhaps Graham) are arguing there is no need for x?
I argue there is no need for w.
Are we going to move to a model where we have four part designations?
Or can we move to a model where version-minor represents *frequent*
and less disruptive releases to incorporate enhancements?
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by Jim Jagielski <ji...@apache.org>.
Bill 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.
Huh? For just one single, simple example, what about APR??
Are we going to now redefine the standards of semantic versioning??
I really don't see how this corrects the "issue" at hand, unless we are constantly also redefining what the "issue" actually is, in which case I grow tired of playing fetch me a rock :)
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by Jacob Champion <ch...@gmail.com>.
On 01/19/2017 01:43 PM, William A Rowe Jr wrote:
> Once this is complete, binary breaking ABI changes would live in
> their own feature development forks. They would never be folded
> into trunk until there was a group consensus to push forward to
> version next.0.0 in the immediate future. trunk/ would cease to be
> a sandbox of ideas unready for release.
I can't comment meaningfully on all of your proposal, but I would like
this part very much. Ideally, I'd like *most* changes (that are more
complex than a single patch) to be part of a feature branch, whether
they're ABI breakers or not, to help with backporting. But having trunk
be closer to release-ready at all times would be a big step forward.
(Aside: my current experiment with a feature branch, for the in-tree
tests in trunk, is somewhat inconclusive. I screwed up the invocations
and used a deprecated merge strategy, and I suspect it won't backport as
cleanly as I wanted it to. Live and learn.)
--Jacob
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by Reindl Harald <h....@thelounge.net>.
Am 19.01.2017 um 22:43 schrieb William A Rowe Jr:
> 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
every PHP version in the past decade (5.3, 5.4, 5.6, 7.0, 7.1, 7.2) is a
ABI breakage by definition and that's what the second number in the
version stands for (major.minor.revision)
the same for MySQL 5.0, 5.1 and 5.5 all changed the ABI and caused mass
rebuilds of linux distributions for every depending package
sorry but no idea how you come to that conclusion
however, the ABI change don't bother the userbase, incompatible config
changes when the software don't know something like warnings but refuse
to start when there is a option which is from a later release or a
option which was removed is what brings people in trouble like one
needed weeks to migrate every peice of configuration inclduding
.htaccess files where you still have the same problem when you install
Magento and did not disable .htaccess entirely
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 20.01.2017 um 21:37 schrieb Graham Leggett <mi...@sharp.fm>:
>
> On 20 Jan 2017, at 7:47 PM, David Zuelke <dz...@heroku.com> wrote:
>
>> I'd actually like to question the whole practice of porting features back to older branches. I think that's the core reason why trunk is in total disarray, and why no substantial releases have been made. There is just no reason for anyone to push forward the state of 2.6 or even 3.0 if you can just backport whatever you want.
>
> The reason this is bad is because Apache httpd comes with a module ecosystem - when you move from httpd v2.0 to v2.2 to v2.4 to v2.6, or rules are that the ABI can break, and therefore all modules that depend on that version must be recompiled. This includes modules that are closed source and offered by a proprietary vendor, or are open source but provided in binary form by a distro.
>
> Right now, you can get new features on the httpd v2.4 branch, but ONLY if that feature does not break existing behaviour in any way. This is entirely reasonable, convenient, and what we’ve been doing since the 1990s.
Agree to the plan. I can see only one exception to this and that is the experimental HTTP/2 support. The introduction of slave connections is NOT ENTIRELY backward compatible. I try to make this as compatible as possible, but there are limits.
>> [...]
>> I have said this in the other thread that hasn't gotten much traction ("A new release process?"). The PHP team was in the exact same spot as HTTPD a few years ago. No substantial progress, stale branches, no light at the end of the tunnel, and a lot of fighting.
>
> We’ve had a significant amount of progress, a trunk that is so stable that almost all fixes and features can be backported to v2.4 without any fear of incompatibility, and the “fighting” is limited to very few individuals.
>
> We’re not broken, we don’t need fixing.
Agreed.
>
> Regards,
> Graham
> —
>
Stefan Eissing
<green/>bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by Reindl Harald <h....@thelounge.net>.
Am 26.01.2017 um 00:20 schrieb David Zuelke:
> On 20.01.2017, at 21:37, Graham Leggett <mi...@sharp.fm> wrote:
>>
>> On 20 Jan 2017, at 7:47 PM, David Zuelke <dz...@heroku.com> wrote:
>>
>>> I'd actually like to question the whole practice of porting features back to older branches. I think that's the core reason why trunk is in total disarray, and why no substantial releases have been made. There is just no reason for anyone to push forward the state of 2.6 or even 3.0 if you can just backport whatever you want.
>>
>> The reason this is bad is because Apache httpd comes with a module ecosystem - when you move from httpd v2.0 to v2.2 to v2.4 to v2.6, or rules are that the ABI can break, and therefore all modules that depend on that version must be recompiled. This includes modules that are closed source and offered by a proprietary vendor, or are open source but provided in binary form by a distro.
>
> Yeah, I hadn't considered proprietary modules.
>
> To take the PHP example, ABI and API changes are usually minimal, so most extensions build pretty cleanly; if not, then they can be fixed, and with most stuff on GitHub these days, that's usually a PR away. Development cycles of extensions have definitely sped up together with the language runtime.
>
> Do people who run a non-distro httpd really install distro-provided modules though?
yes - i build httpd, mod_security, apr, php, pecl-extensions from source
(own rpm packages) but don't want to maintain the whole subversion
package and it's build-dependencies too (mod_dav_svn)
but on the other hand in that case i won't jump to the next httpd
release until the distribution (Fedora) does, at least not for a larger
timeframe than prepare the upgrade on a testing vm
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by David Zuelke <dz...@heroku.com>.
On 20.01.2017, at 21:37, Graham Leggett <mi...@sharp.fm> wrote:
>
> On 20 Jan 2017, at 7:47 PM, David Zuelke <dz...@heroku.com> wrote:
>
>> I'd actually like to question the whole practice of porting features back to older branches. I think that's the core reason why trunk is in total disarray, and why no substantial releases have been made. There is just no reason for anyone to push forward the state of 2.6 or even 3.0 if you can just backport whatever you want.
>
> The reason this is bad is because Apache httpd comes with a module ecosystem - when you move from httpd v2.0 to v2.2 to v2.4 to v2.6, or rules are that the ABI can break, and therefore all modules that depend on that version must be recompiled. This includes modules that are closed source and offered by a proprietary vendor, or are open source but provided in binary form by a distro.
Yeah, I hadn't considered proprietary modules.
To take the PHP example, ABI and API changes are usually minimal, so most extensions build pretty cleanly; if not, then they can be fixed, and with most stuff on GitHub these days, that's usually a PR away. Development cycles of extensions have definitely sped up together with the language runtime.
Do people who run a non-distro httpd really install distro-provided modules though?
> Right now, you can get new features on the httpd v2.4 branch, but ONLY if that feature does not break existing behaviour in any way. This is entirely reasonable, convenient, and what we’ve been doing since the 1990s.
>
>> Just define 2.4 as "bug fixes only" the moment 2.6 is released, and start the process of getting 2.6 out ASAP. In fact, why not declare 2.4 that right now? It's already "stable". It doesn't need more features that suddenly change behavior from 2.4.28 to 2.4.29 or whatever (that's the opposite of what users are looking for).
>>
>> That's how PHP does it now... new features can go into x.y.0, and once that is released (actually, once it's in beta stage), anything that is not a small fix needs to wait for x.y+1.0 or x+1.0.0. Which is not a big deal because these releases land every year now, like clockwork.
>
> So you have to wait a year for new features to see a release? Definitely not keen on that.
Yeah, new features as in new functions, or new language constructs. Useful, because it makes for a consistent API in userland for x.y release series. Not applicable to httpd as a model, I'm sure.
>
>> I have said this in the other thread that hasn't gotten much traction ("A new release process?"). The PHP team was in the exact same spot as HTTPD a few years ago. No substantial progress, stale branches, no light at the end of the tunnel, and a lot of fighting.
>
> We’ve had a significant amount of progress, a trunk that is so stable that almost all fixes and features can be backported to v2.4 without any fear of incompatibility, and the “fighting” is limited to very few individuals.
Alright :)
My calling of trunk as being in "disarray" was also due to some people often vocally complaining about stale or half-done features that have been in there for (allegedly) years, without a backport etc. Didn't mean it as an insult to anyone!
David
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by Ruediger Pluem <rp...@apache.org>.
On 01/20/2017 09:37 PM, Graham Leggett wrote:
> On 20 Jan 2017, at 7:47 PM, David Zuelke <dz...@heroku.com> wrote:
>
>> I'd actually like to question the whole practice of porting features back to older branches. I think that's the core reason why trunk is in total disarray, and why no substantial releases have been made. There is just no reason for anyone to push forward the state of 2.6 or even 3.0 if you can just backport whatever you want.
>
> The reason this is bad is because Apache httpd comes with a module ecosystem - when you move from httpd v2.0 to v2.2 to v2.4 to v2.6, or rules are that the ABI can break, and therefore all modules that depend on that version must be recompiled. This includes modules that are closed source and offered by a proprietary vendor, or are open source but provided in binary form by a distro.
I share this concern. If you put new features only in 2.current+1 then most users have to wait for years until they can
use them due to the lack of support by third parties for 2.current+1. You might argue if you speed up with increasing
x in 2.x and faster deprecating older 2.y you would solve that issue and 3rd parties would simply speed up their model.
But I don't think so. I think and some actually do they would create there own fork of 2.x and only supply the
modules for that fork leaving you locked in a closed vendor solution with "features" added by them. Nothing I am keen on.
>
> Right now, you can get new features on the httpd v2.4 branch, but ONLY if that feature does not break existing behaviour in any way. This is entirely reasonable, convenient, and what we\u2019ve been doing since the 1990s.
>
>> Just define 2.4 as "bug fixes only" the moment 2.6 is released, and start the process of getting 2.6 out ASAP. In fact, why not declare 2.4 that right now? It's already "stable". It doesn't need more features that suddenly change behavior from 2.4.28 to 2.4.29 or whatever (that's the opposite of what users are looking for).
>>
>> That's how PHP does it now... new features can go into x.y.0, and once that is released (actually, once it's in beta stage), anything that is not a small fix needs to wait for x.y+1.0 or x+1.0.0. Which is not a big deal because these releases land every year now, like clockwork.
>
> So you have to wait a year for new features to see a release? Definitely not keen on that.
>
>> I have said this in the other thread that hasn't gotten much traction ("A new release process?"). The PHP team was in the exact same spot as HTTPD a few years ago. No substantial progress, stale branches, no light at the end of the tunnel, and a lot of fighting.
>
> We\u2019ve had a significant amount of progress, a trunk that is so stable that almost all fixes and features can be backported to v2.4 without any fear of incompatibility, and the \u201cfighting\u201d is limited to very few individuals.
>
> We\u2019re not broken, we don\u2019t need fixing.
I wouldn't say we don't need fixing. But IMHO we don't need fixing in the way proposed.
We need to work on getting a better testing in place. Honestly I don't have an answer at hand how to do this,
but from my personal point of view I think that our perl framework is sometimes a little hard to work with
(might be my own limitation) and we lack the possibility of doing internal API tests more easily (I know that you can do
certain tests by creating C test modules in the perl framework, but that should be easier).
That would increase stability of our release and avoid regressions better.
But the cause for introducing regressions isn't because a feature is ported back, we have regressions as well on bug
fixes, the cause is in most cases the complexity of the code ported back or better the complexity of the code region
touched.
And by complexity in this case I don't mean necessarily the number of code lines ported back. A one line change can
cause ugly regressions if it messes with a complex subject.
But maybe that tells us that we need to restructure these areas of code to make them easier to understand and thus
more stable to changes.
Honestly the stuff above sounds like a lot of thankless work and not sexy and that maybe the reason why we lack progress
here.
Regards
R�diger
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jan 20, 2017, at 3:37 PM, Graham Leggett <mi...@sharp.fm> wrote:
>
>
> We’ve had a significant amount of progress, a trunk that is so stable that almost all fixes and features can be backported to v2.4 without any fear of incompatibility, and the “fighting” is limited to very few individuals.
>
> We’re not broken, we don’t need fixing.
>
Here here!!
++1!
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by Graham Leggett <mi...@sharp.fm>.
On 20 Jan 2017, at 7:47 PM, David Zuelke <dz...@heroku.com> wrote:
> I'd actually like to question the whole practice of porting features back to older branches. I think that's the core reason why trunk is in total disarray, and why no substantial releases have been made. There is just no reason for anyone to push forward the state of 2.6 or even 3.0 if you can just backport whatever you want.
The reason this is bad is because Apache httpd comes with a module ecosystem - when you move from httpd v2.0 to v2.2 to v2.4 to v2.6, or rules are that the ABI can break, and therefore all modules that depend on that version must be recompiled. This includes modules that are closed source and offered by a proprietary vendor, or are open source but provided in binary form by a distro.
Right now, you can get new features on the httpd v2.4 branch, but ONLY if that feature does not break existing behaviour in any way. This is entirely reasonable, convenient, and what we’ve been doing since the 1990s.
> Just define 2.4 as "bug fixes only" the moment 2.6 is released, and start the process of getting 2.6 out ASAP. In fact, why not declare 2.4 that right now? It's already "stable". It doesn't need more features that suddenly change behavior from 2.4.28 to 2.4.29 or whatever (that's the opposite of what users are looking for).
>
> That's how PHP does it now... new features can go into x.y.0, and once that is released (actually, once it's in beta stage), anything that is not a small fix needs to wait for x.y+1.0 or x+1.0.0. Which is not a big deal because these releases land every year now, like clockwork.
So you have to wait a year for new features to see a release? Definitely not keen on that.
> I have said this in the other thread that hasn't gotten much traction ("A new release process?"). The PHP team was in the exact same spot as HTTPD a few years ago. No substantial progress, stale branches, no light at the end of the tunnel, and a lot of fighting.
We’ve had a significant amount of progress, a trunk that is so stable that almost all fixes and features can be backported to v2.4 without any fear of incompatibility, and the “fighting” is limited to very few individuals.
We’re not broken, we don’t need fixing.
Regards,
Graham
—
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by Eric Covener <co...@gmail.com>.
On Fri, Jan 20, 2017 at 12:47 PM, David Zuelke <dz...@heroku.com> wrote:
> I'd actually like to question the whole practice of porting features back to older branches. I think that's the core reason why trunk is in total disarray, and why no substantial releases have been made. There is just no reason for anyone to push forward the state of 2.6 or even 3.0 if you can just backport whatever you want.
IMO trunk isn't in total disarray, and new releases haven't been made
because there's nobody working/waiting on anything that doesn't fit
into 2.4 as a continuous delivery release. Maintenance has been just
as disruptive as new features.
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 20.01.2017 um 21:40 schrieb Jim Jagielski <ji...@jaguNET.com>:
>
>
>> On Jan 20, 2017, at 3:36 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
>>
>>
>> If I really was the dictator Bill tries to insinuate that I am,
>> I would simply branch 2.5 *right now* off of trunk.
>
> In fact, I'd announce 2.5-alpha "immediately" as what's
> in trunk... with a set schedule that 2.6-Beta1 is tagged 2
> months later and a goal that 2.6-GA be announced at
> ApacheCon Miami.
>
> But this all implies that 2.5/2.6 not be the huge restructure/re-
> factor envisioned by some.
Let's sort out what will be in it and what everyone is willing to commit to in that time frame. Define what 2.6 will be with all the restrictions on time and effort that we can do. Then we can have a look at it and see if it's worthwhile for us and our users to do.
I hope that leads to a more fruitful discussion. Debating castles in the sky is not what I am interested in.
Stefan Eissing
<green/>bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by Graham Leggett <mi...@sharp.fm>.
On 20 Jan 2017, at 10:40 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
> In fact, I'd announce 2.5-alpha "immediately" as what's
> in trunk... with a set schedule that 2.6-Beta1 is tagged 2
> months later and a goal that 2.6-GA be announced at
> ApacheCon Miami.
>
> But this all implies that 2.5/2.6 not be the huge restructure/re-
> factor envisioned by some.
I’m keen to see v2.5-alpha out soon.
There will be a drive to ensure the new goodness on trunk is stable and fixed, and this is a good thing.
Regards,
Graham
—
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jan 20, 2017, at 3:36 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
>
> If I really was the dictator Bill tries to insinuate that I am,
> I would simply branch 2.5 *right now* off of trunk.
In fact, I'd announce 2.5-alpha "immediately" as what's
in trunk... with a set schedule that 2.6-Beta1 is tagged 2
months later and a goal that 2.6-GA be announced at
ApacheCon Miami.
But this all implies that 2.5/2.6 not be the huge restructure/re-
factor envisioned by some.
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jan 20, 2017, at 12:47 PM, David Zuelke <dz...@heroku.com> wrote:
>
>
> I'd actually like to question the whole practice of porting features back to older branches. I think that's the core reason why trunk is in total disarray, and why no substantial releases have been made. There is just no reason for anyone to push forward the state of 2.6 or even 3.0 if you can just backport whatever you want.
>
> Just define 2.4 as "bug fixes only" the moment 2.6 is released, and start the process of getting 2.6 out ASAP. In fact, why not declare 2.4 that right now? It's already "stable". It doesn't need more features that suddenly change behavior from 2.4.28 to 2.4.29 or whatever (that's the opposite of what users are looking for).
Ummm... that's kind of the goal. You are telling us nothing we
don't already know. The issue is that 2.6 has been stuck in
a holding pattern, and it is unfair to our users, and our
developers, to have good, useful features locked in trunk
with no hope of reaching outside for some unknown amount of
time.
So, you say, the question is Why Not Work On 2.6 And Push Getting
That Out. The reason is because some people then want/desire/demand
huge restructurings in 2.6, which means, of course, that forking/
branching off 2.5/2.6 is the EASY part. The hard part is controlling
the urge to then go "wild" on 2.5/2.6, which drastically increases
the time until we finally get GA. And some people also want NO NEW
FEATURES in 2.4 during this whole timeframe. I know, crazy.
If I really was the dictator Bill tries to insinuate that I am,
I would simply branch 2.5 *right now* off of trunk. And then
say the goal is to get 2.5 stable enough to go GA as 2.6... no
big restructuring, no huge and invasive API changes. These are
all good, and needed, but if the goal is to make 2.4 our 2.2-like
"stable and no new features" branch, we need a 2.6 that happens
SOON.
And finally, I don't believe at ALL that things are as dire as
Bill claims nor that trunk is "in total disarray" as you state.
I do appreciate the insight related to PHP. It goes well with
the insight on how lots and lots of other projects handle
this. But what works for PHP, a language, may not necessarily
work for httpd, a commodity server.
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by David Zuelke <dz...@heroku.com>.
> On 20.01.2017, at 15:34, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> On Thu, Jan 19, 2017 at 6:12 PM, David Zuelke <dz...@heroku.com> wrote:
>> I don't know any framework/language/library out there that handles it that strictly. Nginx, or Ruby, or PHP, or whatever...
>>
>> From x.y.z to x.y.z+1, retain full compatibility.
>>
>> From x.y.z to x.y+1.0, keep external API compatibility, break ABI if needed, break internal API if absolutely needed
>>
>> From x.y.z to x+1.0.0, break anything you want.
>>
>> One issue IMO is that there are a lot of things in flight for 2.6 and 3.0, and some of these are features, while other are big architectural overhauls. The former are for 2.6, and the latter very clearly belong into 3.0. There's no reason why both can't be worked on concurrently.
>
> That's what I'm proposing... a model where x.y.[0-#] releases remain consistent,
> like all the packages you mention above, and unlike httpd.
>
> I liked your highlight of "if [absolutely] needed". That's where our
> trunk (2.next)
> has spent four years diverging from 2.current, mostly unnecessarily.
>
> The fact that the code *could* be backported to 2.4.x (in your PHP and Ruby
> examples, such backports aren't even acceptable) means that it *could* have
> stayed consistent on our 2.next trunk.
I'd actually like to question the whole practice of porting features back to older branches. I think that's the core reason why trunk is in total disarray, and why no substantial releases have been made. There is just no reason for anyone to push forward the state of 2.6 or even 3.0 if you can just backport whatever you want.
Just define 2.4 as "bug fixes only" the moment 2.6 is released, and start the process of getting 2.6 out ASAP. In fact, why not declare 2.4 that right now? It's already "stable". It doesn't need more features that suddenly change behavior from 2.4.28 to 2.4.29 or whatever (that's the opposite of what users are looking for).
That's how PHP does it now... new features can go into x.y.0, and once that is released (actually, once it's in beta stage), anything that is not a small fix needs to wait for x.y+1.0 or x+1.0.0. Which is not a big deal because these releases land every year now, like clockwork.
I have said this in the other thread that hasn't gotten much traction ("A new release process?"). The PHP team was in the exact same spot as HTTPD a few years ago. No substantial progress, stale branches, no light at the end of the tunnel, and a lot of fighting.
A structured release process fixed all that.
David
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Jan 19, 2017 at 6:12 PM, David Zuelke <dz...@heroku.com> wrote:
> I don't know any framework/language/library out there that handles it that strictly. Nginx, or Ruby, or PHP, or whatever...
>
> From x.y.z to x.y.z+1, retain full compatibility.
>
> From x.y.z to x.y+1.0, keep external API compatibility, break ABI if needed, break internal API if absolutely needed
>
> From x.y.z to x+1.0.0, break anything you want.
>
> One issue IMO is that there are a lot of things in flight for 2.6 and 3.0, and some of these are features, while other are big architectural overhauls. The former are for 2.6, and the latter very clearly belong into 3.0. There's no reason why both can't be worked on concurrently.
That's what I'm proposing... a model where x.y.[0-#] releases remain consistent,
like all the packages you mention above, and unlike httpd.
I liked your highlight of "if [absolutely] needed". That's where our
trunk (2.next)
has spent four years diverging from 2.current, mostly unnecessarily.
The fact that the code *could* be backported to 2.4.x (in your PHP and Ruby
examples, such backports aren't even acceptable) means that it *could* have
stayed consistent on our 2.next trunk.
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by David Zuelke <dz...@heroku.com>.
I don't know any framework/language/library out there that handles it that strictly. Nginx, or Ruby, or PHP, or whatever...
From x.y.z to x.y.z+1, retain full compatibility.
From x.y.z to x.y+1.0, keep external API compatibility, break ABI if needed, break internal API if absolutely needed
From x.y.z to x+1.0.0, break anything you want.
One issue IMO is that there are a lot of things in flight for 2.6 and 3.0, and some of these are features, while other are big architectural overhauls. The former are for 2.6, and the latter very clearly belong into 3.0. There's no reason why both can't be worked on concurrently.
> On 19.01.2017, at 22:43, 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.
>
> 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.
>
> There might be some minor breakage that requires a recompilation,
> such as a user module allocating a req_rec. That is solved by setting
> a showstopper to the 2.next release to introduce _create() accessors
> to every structure belonging to the httpd API. There would be side
> determinations... would we institute such a change with the release
> of 2.5, or 2.6, or 3.0?
>
> Once this is complete, binary breaking ABI changes would live in
> their own feature development forks. They would never be folded
> into trunk until there was a group consensus to push forward to
> version next.0.0 in the immediate future. trunk/ would cease to be
> a sandbox of ideas unready for release.
>
> It's likely a couple-week process that I can't start till the end of next
> week. But I think the frustration about not being able to ship new
> features has a lot to do with our history of breaking API's every time
> we ticked up the version minor number.
>
> It might be that we won't end up shipping 2.6 because other good
> and necessary binary-breaking-changes occur between now and
> in the near future, or that these exist on trunk. But if we defer the
> gruntwork of renaming things and whitespace mop-up etc until
> a short several-week period prior to the actual major.0.0 release,
> then we can keep trunk/ in a much more releasable state for all
> the new features.
>
> We may have the impetus for a 3.0 release in the near future, we
> may not, but I'm sure the idea that 2.5 is a 'major' ABI-breaking
> release is not serving us well.
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 20.01.2017 um 01:46 schrieb Eric Covener <co...@gmail.com>:
>
> On Thu, Jan 19, 2017 at 4: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.
>>
>> 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
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Jan 20, 2017, at 9:26 AM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
>
> Just so we are all in agreement, 2.4 has been neither conservative nor
> maintenance in any conventional sense, for the past four years. Instead
> we have users relying on the stable 2.2 release which we will discard
> midyear, 4 1/2 years after 2.4 had shipped.
>
We are NOT in agreement. You just saying so is not proof of
the fact, nor constantly repeating it does not mean that "we
are all in agreement".
Stop trying to steamroll this Bill... it's not productive.
If you put half as much effort into actually coding stuff
in httpd as you do on these long, rambling rants, things
would be much better.
All this crap about redefining minor, and number and all
that is wasteful and simply constantly changing the goal
posts and does NOTHING to address the issue at hand.
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Jan 19, 2017 at 6:46 PM, Eric Covener <co...@gmail.com> wrote:
> On Thu, Jan 19, 2017 at 4: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.
>>
>> 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?
Just so we are all in agreement, 2.4 has been neither conservative nor
maintenance in any conventional sense, for the past four years. Instead
we have users relying on the stable 2.2 release which we will discard
midyear, 4 1/2 years after 2.4 had shipped.
> New major/minor downstream releases can jump to 2.6 without much fuss,
> and current ones can try to track closer to current 2.4.x as they age.
What I'm proposing is that 2.6.0, 2.8.0, 2.10.0 (or we get out of odds/evens
at this point) are rapid feature releases, no less often than once a year.
For some arbitrary period, perhaps a year, fixes are applied to 2.prior.n+1
and yes, those can be tracked. Users can pick the .zero release to grab
the new features now, or wait for .1 or .2 to pick up any regression fixes.
But within two years, not four, 2.prior would be abandoned as 2.current
has been stabilizing (no features after .0) and 2.next (new features) is
about to be released.
This is closer to the model at most other ASF projects.
> We can find some new religion about how trunk work if some concise
> policy doc appears that we can all agree on.
That's the next step after concluding these dialogs, to weave together the
desires of the divergent committers' interests.
On Fri, Jan 20, 2017 at 3:09 AM, Stefan Eissing
<st...@greenbytes.de> wrote:
>
> Just some brainstorming:
>
> LTS/Stable/Feature branches
>
> 2.2.x/2.4.x/2.6.x for now
Note 2.2.x is not LTS. It is EOL July.
> 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
So 2.4.x again is implicitly unstable.
> 2.2.x/2.4.x/2.8.x in extreme cases, we could ditch a feature branch and move on.
Note that I'm suggesting *much* more frequent version minor releases.
I'd like to see us get *all* new features in users hands within 12
months of first commit.
Not the current pattern not those few which are backported and
destablizing to the
current release - vs those which are not backported, not tested, and
destablizing to
current vs. trunk repository contents.
I think it obviates the need for {even} {odd} if we move rapidly from
2.5.0-beta to
2.5.1-beta to 2.5.2-GA - branch trunk at 2.5.2-GA or 2.5.1-beta for
all new feature
work toward 2.6.0 and ensure 2.6.0-beta gets shipped in months, not a
half decade.
> - 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
Note I'm suggesting that 2.current and 2.prior get fixes. We can leave the
hassle of backporting further than that to commercial or other endeavors, there
should be no point in time where the choice between those two is worse than
staying back at 2.ancient.
Note I'm suggesting that feature is 2.5.0-beta, 2.5.1-beta, right up until we
declare 2.5.x-GA. That release no longer gets enhancement/features, but
at that point we already have 2.6.0-beta trunk to keep bringing in the new
features.
This might look midyear like;
2.2.x - end of life, abandoned
2.4.x-GA - stable legacy
2.5.2-GA - stable (following a 2.5.0-beta & 2.5.1-beta of features/enhancements)
trunk - not released yet, but promised a 2.6.0-beta release within months
At that point we have three to maintain at a time, future, current, and one
immediately past branch. Not so different from what we have now, except
that 2.5.x isn't going through the churn 2.4.x did, while 2.6.x dev is ensured
to be a beta very soon if we agree we are collecting these features in trunk
with an actual assurance that it really will be released on an annual basis
if not even more frequently.
Amusingly, the docs for 2.5.7 will be the same docs as for 2.5.2, if the goal
posts no longer keep running up and back down the field. Much of the docs
groups effort to have 2.6.0 documented when we release won't have to be
backported at all.
> (and there could be odd version numbers in there as well, but does not matter to me)
I agree we should discard odd/even convention, if the accepted 2.5.x-beta
is adopted as GA.
>> But I think the frustration about not being able to ship new
>> features has a lot to do with our history of breaking API's every time
>> we ticked up the version minor number.
>
> Is there a (remarkable) inability to ship new features today? Somehow
> simultaneously with too many new features shipping in 2.4.x? I'm not
> following this part.
There is no inability to ship new features today, there is an inability to keep
the current release anywhere approaching stable. The only stable branch
from a user's perspective is 2.2 which is absurd.
If we take a hard line on stable branch enhancements, there becomes
frustration if minor releases to include those features aren't forthcoming.
So the default operating mode of httpd has been to shoehorn every new
feature into the next subversion release, because otherwise your new
feature might be waiting four years to see daylight.
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by Eric Covener <co...@gmail.com>.
On Thu, Jan 19, 2017 at 4: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.
>
> 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?
New major/minor downstream releases can jump to 2.6 without much fuss,
and current ones can try to track closer to current 2.4.x as they age.
We can find some new religion about how trunk work if some concise
policy doc appears that we can all agree on.
> But I think the frustration about not being able to ship new
> features has a lot to do with our history of breaking API's every time
> we ticked up the version minor number.
Is there a (remarkable) inability to ship new features today? Somehow
simultaneously with too many new features shipping in 2.4.x? I'm not
following this part.
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by Graham Leggett <mi...@sharp.fm>.
On 20 Jan 2017, at 4:29 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>> 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.
This would be an abuse of the veto mechanism - the veto is to protect the project, not force other people to do work on your behalf, whether “invited” to or not.
In a case like this, what you’d be expected to do is write and commit patches that fixed any cases you felt was unnecessary yourself, and have those patches reviewed by the rest of the project in the normal way.
> In light of your objection, I won't proceed with a preservation
> branch, but take the veto knife directly to trunk.
As per our rules a veto requires a technical justification. Breaking changes are allowed on trunk, and so the fact the change is breaking is not in itself sufficient justification for a 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.
>
> 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.
I disagree, sorry.
> Finally the fact that httpd's last release was Feb '12 indicates to me
> a project at risk.
The last releases occurred in Dec ’16 and Jan ’17 respectively.
If you want to see trunk released, let’s branch and release v2.5.x in anticipation of v2.6.x.
Regards,
Graham
—
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Fri, Jan 20, 2017 at 4:04 AM, Graham Leggett <mi...@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.
Re: Reset out x.minor.z definition of 'minor' at httpd?
Posted by Graham Leggett <mi...@sharp.fm>.
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.
> 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).
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.
Regards,
Graham
—