> -----Ursprüngliche Nachricht----- > Von: David Zuelke <dzue...@salesforce.com> > Gesendet: Montag, 23. April 2018 18:09 > An: dev@httpd.apache.org > Betreff: Re: Revisit Versioning? (Was: 2.4.3x regression w/SSL vhost > configs) > > On Sat, Apr 21, 2018 at 12:45 PM, Graham Leggett <minf...@sharp.fm> > wrote: > > On 19 Apr 2018, at 5:55 PM, David Zuelke <dzue...@salesforce.com> > wrote: > > > >> I hate to break this to you, and I do not want to discredit the > >> amazing work all the contributors here are doing, but httpd 2.4 is of > >> miserable, miserable quality when it comes to breaks and regressions. > >> > >> I maintain the PHP/Apache/Nginx infrastructure at Heroku, and I was > >> able to use the following httpd releases only in the last ~2.5 years: > >> > >> - 2.4.16 > >> - 2.4.18 > >> - 2.4.20 > >> - 2.4.29 > >> -2.4.33 > >> > >> Mostly because of regressions around mod_proxy(_fcgi), REDIRECT_URL, > whatever. > > > > Did you bring these regressions to our attention? Regressions get fix > very quickly - there was an 18 month period between 2.4.20 and 2.4.29, > what stopped it being possible to upgrade in that time? > > I double checked. It was actually 2.4.27, not 2.4.29; 15 months, not 18. > My bad. > > The issue was the PHP-FPM + mod_proxy_fcgi regression introduced in > 2.4.21; it got reported pretty quickly but took a while to address. > > It finally got fixed in 2.4.26: > https://bz.apache.org/bugzilla/show_bug.cgi?id=60576 > > But that fix broke SCRIPT_NAME: > https://bz.apache.org/bugzilla/show_bug.cgi?id=61202 > > So 2.4.27 was functional again. > > That means between April 11, 2016, and July 11, 2017, httpd with > mod_proxy_fcgi and PHP-FPM was broken. > > The original change was made against trunk > (https://bz.apache.org/bugzilla/show_bug.cgi?id=59618) and then > backported to 2.4.next.
Which was an unfortunate regression that took long to be fixed correctly, but as far as I remember it did not involve any new features nor refactoring. "Just" a bugfix that caused a regression that was hard to fix. > > > > > (As other people have said, there was no release between 2.4.16 and > 2.4.18, 2.4.19 was replaced two weeks later, and there were no releases > for you to have used between v2.4.29 and 2.4.33) > > > >> This is not any person's fault. This is the fault of the process. The > >> process can be repaired: bugfixes only in 2.4.x, do RC cycles for > >> bugfix releases as well (that alone makes the changelog look a lot > >> less confusing, which is useful for the project's image, see also the > >> Nginx marketing/FUD discussion in the other thread), and start > testing > >> new features in modules first. > > > > Unfortunately this misses a fundamental reality of what the httpd > project is - we are the foundation under many many other things, and > when we jump from v2.4.x to v2.6.x, our complete ecosystem above us > needs to be recompiled. > > Going from 2.4.x to 2.6.0 doesn't mean that 2.4.x would no longer be > maintained. There could easily be some predictable, defined support > policy for keeping older versions alive. Which requires enough manpower to maintain all these branches. Looking at the past 15 years we never maintained more than two stable branches at the same time. This is no argument against 2.6.0 as we currently only maintain 2.4.x, but against having 2.6+n.0 each time we want to add new features and keep maintaining 2.6+n-x.0 I think experience shows that if we would release 2.6 the activity to backport new features to 2.4 would drop over time. > > The other thing is ABI versus API stability; you could say 2.x. > versions retain API compatibility, but not ABI compatibility, so while > modules would have to be rebuilt against newer version series, that > could in virtually all cases happen without having to touch the > module's code. This might work with open source modules, but even here you would lose the chance e.g. on LTS distributions to compile your own Apache with later features being on the same ABI level as the OS delivered Apache and install a OS delivered package of a module to use it with this instead of needing to compile it on your own. It does not work at all with closed source modules, because as soon as these vendors need to recompile you will either have to wait for a longer period of time or need to upgrade their product as well to a newer version. > > >> It makes such little sense to land h2 support in 2.4.something, as > >> opposed to having it as an official "brand new, try it out" > subproject > >> first, and then bundle it with 2.6. > > > > Not only does it make sense, but it is vital we do so. > > > > We needed to get h2 support into the hands of end users - end users > who were not going to recompile their entire web stack, who install > software from distros who are not going to upgrade, who were deploying > modules from vendors that were not going to recompile. > > But that's what I'm saying. Why was h2 not kept as a module (for the > few people that are already deploying HTTP/2 stacks), let it mature It is a module. Nobody was forced to use it. As mentioned it was experimental in the beginning. This means it was not compiled by default and the backport procedure was much faster and less strict (this changed as soon as the experimental status was removed). But it matured very quickly that way as it was already used by lots of users that wanted to use this experimental module and that understood its status being experimental. People who did not want to take the risk just did not use it. > this way, and then put it into everyone's hands as part of 2.6.0, > which could be the big shiny new feature, to give everyone an > incentive to move to that new major version? > > > Our average user will deploy whatever comes by default on their > operating system, they’re not going to have a dedicated team that > deploys a custom stack for their application. It is vital we respect the > needs of these groups of users. > > That is even more of an argument to move to a more predictable cycle > and have patch releases only fix issues, because it means new features > see the light of day more quickly, so more people who just use what > comes with their OS would benefit from them. > > Nobody who uses Apache as part of Debian, Ubuntu, RHEL, whatever, gets > new 2.4.next features. Those distros freeze Apache at whatever is the > latest version when their cutoff date is due, and then only backport > security fixes. This is true, but they don't get them with another versioning as well. But with the current approach they can just compile Apache and use the 3rd party modules from the distribution. Regards Rüdiger
