httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Zuelke>
Subject Re: Reset out x.minor.z definition of 'minor' at httpd?
Date Fri, 20 Jan 2017 17:47:10 GMT

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


View raw message