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. > > (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. 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. >> 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 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. >> Really, I'd suggest taking a close look at the PHP release cycle, with >> their schedules, their RFC policies, everything. As I said in that >> other thread, the PHP project was in exactly the same spot a few years >> ago and they have pulled themselves out of that mess with amazing >> results. > > Specifically what about the php release cycle are you referring to? I was > burned badly a number of years ago by php config file formats being changed > in point releases, have they improved their stability? Yes. Nothing like that has happened since PHP 5.4, when the new release process started and all of this got fixed. I explained this several times in this thread, other threads, and the thread a year plus ago I linked to. David
