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