On Sat, Apr 14, 2018 at 8:48 AM, Jim Jagielski <j...@jagunet.com> wrote: > IMO, the below ignores the impacts on OS distributors who > provide httpd. We have seen how long it takes for them > to go from 2.2 to 2.4...
They went to 2.4 once 2.4 was no longer beta. There is this concept called "code freeze". At that point in the most modern OS distribution (for the few weeks that lasts), Ubuntu 18.04 ships with... Apache httpd 2.4.29 Apache apr 1.6.3 Apache apr-util 1.6.1 libcurl 7.58 OpenSSL 1.1.0g nghttp2 1.30.0 brotli 1.0.3 Expat 2.2.5 jansson 2.11 libxml2 2.9.4 lua 5.3.3 PCRE 8.39 + 10.31 ZLib 1.2.11 How long will it take Ubuntu to pick up 2.4.next + OpenSSL 1.1.1 to support TLSv1.3? Answer: next release, the 18.04 ship sailed. And everything contributed to 2.4.33 release? All in vain. None of that in this OS distribution, because, code freeze. Nobody installing Ubuntu 18.04 finds TLSv1.3 from OpenSSL and their consuming programs out of the box. This means 18.10, or 20.04, 2 years from now - for those "stable" users. The only thing this imaginary numbering question provokes is fear of moving the project forwards. In the time its taken this project to make minor tweaks around the edges in httpd, and jump forward by only a handful of large leaps over 20 years, how many versions did our primary open-source consumers release? Ubuntu 18.04 again - the only thing almost as slow as httpd evolution has been lynx; chromium 65 firefox 59 konqueror 17 lynx 2.8.9 Thanks David, and Nick, for trying to dispel this paranoia that version numbers will cause users and distributors to flee the project. Here's my concern, if .subversion meant bug fix (and bug fix, only) then httpd distributed across Debian, Ubuntu, Redhat, Fedora, Free/Open/NetBSD etc etc could correspond to something the httpd project released. Because they all cherry pick only "necessary" bug fixes (and each define those differently), not one of them distributes *Apache Software Foundation Apache Web Server httpd*. By mashing all the fun new stuff into the same numbers because adoption yadda yadda, none of them can turn to httpd for the necessary fixes for their distribution, and they certainly can't simply review and rubber stamp our subversion release for the "right" set of bug fixes. The irony in all this is that I was taught "version numbers are cheap" fairly early, by this very project. No truth-in-advertising, that "subversion numbers are cheap, major version numbers are a heavy lift of 20 years of baggage." You also claimed some delay in 2.4 adoption, when there was none in fact. In 2014; January; OpenSUSE 13 ships httpd 2.4.10 March; Ubuntu 14.04 ships httpd 2.4.7 April; RedHat 7 ships httpd 2.4.6 We observe the "code freeze" effect (defined by three different distributors) coupled with distributors deep distrust of our releases, so by continuously polluting our version major.minor release with more and more cruft, those users are denied not only the new cruft, but all the bug fixes to the old cruft as well... there's really no other explanation for the users of one of our most common distributions to be locked out of several subversions worth of bugfix corrections.
