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 Wed, 25 Jan 2017 23:20:18 GMT
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

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!


View raw message