On 20.01.2017, at 21:37, Graham Leggett <minf...@sharp.fm> wrote:
> 
> 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.

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

Reply via email to