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