Re: Reset out x.minor.z definition of 'minor' at httpd?

[Reindl Harald]

Am 26.01.2017 um 00:20 schrieb David Zuelke:

On 20.01.2017, at 21:37, Graham Leggett  wrote:


On 20 Jan 2017, at 7:47 PM, David Zuelke  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?

[David Zuelke]

On 20.01.2017, at 21:37, Graham Leggett  wrote:
> 
> On 20 Jan 2017, at 7:47 PM, David Zuelke  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?

[Graham Leggett]

On 20 Jan 2017, at 10:40 PM, Jim Jagielski  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
—



smime.p7s
Description: S/MIME cryptographic signature

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Ruediger Pluem]

On 01/20/2017 09:37 PM, Graham Leggett wrote:
> On 20 Jan 2017, at 7:47 PM, David Zuelke  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’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.

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?

[Graham Leggett]

On 20 Jan 2017, at 4:29 PM, William A Rowe Jr  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
—



smime.p7s
Description: S/MIME cryptographic signature

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Stefan Eissing]

> Am 20.01.2017 um 21:40 schrieb Jim Jagielski :
> 
> 
>> On Jan 20, 2017, at 3:36 PM, Jim Jagielski  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

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Stefan Eissing]

> Am 20.01.2017 um 21:37 schrieb Graham Leggett :
> 
> On 20 Jan 2017, at 7:47 PM, David Zuelke  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

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Jim Jagielski]

> On Jan 20, 2017, at 3:36 PM, Jim Jagielski  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?

[Jim Jagielski]

> On Jan 20, 2017, at 3:37 PM, Graham Leggett  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?

[Graham Leggett]

On 20 Jan 2017, at 7:47 PM, David Zuelke  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
—



smime.p7s
Description: S/MIME cryptographic signature

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Jim Jagielski]

> On Jan 20, 2017, at 12:47 PM, David Zuelke  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?

[Jim Jagielski]

> On Jan 20, 2017, at 9:26 AM, William A Rowe Jr  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?

[Eric Covener]

On Fri, Jan 20, 2017 at 12:47 PM, David Zuelke  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?

[David Zuelke]

> On 20.01.2017, at 15:34, William A Rowe Jr  wrote:
> 
> On Thu, Jan 19, 2017 at 6:12 PM, David Zuelke  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?

[William A Rowe Jr]

On Thu, Jan 19, 2017 at 6:05 PM, Jim Jagielski  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?

[William A Rowe Jr]

On Thu, Jan 19, 2017 at 6:12 PM, David Zuelke  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?

[William A Rowe Jr]

On Fri, Jan 20, 2017 at 4:04 AM, Graham Leggett  wrote:
> 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.

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 

Re: Reset out x.minor.z definition of 'minor' at httpd?

[William A Rowe Jr]

On Thu, Jan 19, 2017 at 6:46 PM, Eric Covener  wrote:
> On Thu, Jan 19, 2017 at 4: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.
>>
>> 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
 wrote:
>
> Just some brainstorming:
>
> LTS/Stable/Feature branches
>
> 2.2.x/2.4.x/2.6.xfor now

Note 2.2.x is not LTS. It is EOL July.

> 2.2.x/2.6.x/2.8.xif we think new features in 2.6 are stable and want to 
> add more features
> 2.4.x/2.4.x/2.6.xif 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.xin 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 

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Graham Leggett]

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 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
—



smime.p7s
Description: S/MIME cryptographic signature

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Stefan Eissing]

> Am 20.01.2017 um 01:46 schrieb Eric Covener :
> 
> On Thu, Jan 19, 2017 at 4: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.
>> 
>> 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.xfor now
2.2.x/2.6.x/2.8.xif we think new features in 2.6 are stable and want to add 
more features
2.4.x/2.4.x/2.6.xif we end LTS for 2.2, the new LTS can be a stable branch
2.2.x/2.4.x/2.8.xin 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

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: Reset out x.minor.z definition of 'minor' at httpd?

[Eric Covener]

On Thu, Jan 19, 2017 at 4: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.
>
> 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?

[David Zuelke]

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  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?

[Jim Jagielski]

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?

[Jacob Champion]

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?

[Reindl Harald]

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

Reset out x.minor.z definition of 'minor' at httpd?

[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.

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.