On 20 Jan 2017, at 7:47 PM, David Zuelke <d...@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
—
smime.p7s
Description: S/MIME cryptographic signature
