I will preface by stating that you are referring to 2.6.0 or 3.0.0, our next GA, which is not yet what I've suggested on list. I'll start another thread on 2.5.0 development branch, and run with your discussion of the next GA...
On Tue, Oct 24, 2017 at 8:42 AM, Jim Jagielski <[email protected]> wrote: > I would like to start a discussion on 2.5.0 and give > some insights on my thoughts related to it. > > First and foremost: there is cool stuff in 2.5.0 > that I really, REALLY wish were in a releasable, usable > artifact. Up to now, we've been doing these as backports > to the 2.4.x tree with, imo at least, good success. The 2.4.x release series has a >50% regression rate release by release, comparing released 2.4.n to 2.4.prev. I don't consider that 'good'. This is because 2.4 is not a maintenance branch, and is therefore not stable. But we don't have to extend this conversation because I brought up the concern previously and the concern was rejected. A 2.5.x alpha preview branch *with community testers* would have avoided a great number of these regressions, if the community had a chance to test and provide feedback. > So I think the main questions regarding 2.5.0 is a list > of items/issues that simply *cannot* be backported, due > to API/ABI concerns. And then gauge the "value" of > the items on that list. Disagreed. That the code was committed and passively vetoed due to an unwillingness of the project to release it. httpd 2.4.0 was forked at r1200449. This happened 6 years ago as of this coming Nov 10th. What is that code? Discounting all changes to docs/, all changes in whitespace, line endings and propchanges, the remaining delta is; + 36654 lines + 1014607 non-whitespace characters - 17198 lines - 610777 non-whitespace characters > Another would be to look at some of the items currently > "on hold" for backporting, due to outstanding questions, > tech issues, more needed work/QA, etc... IMO, if these > backports lack "support" for 2.4.x, then I wonder how > "reliable" they are (or how tested they are) in the 2.5.o > tree. And if the answer is "we pull them out of 2.5.0" > then the question after that is what really *are* the > diffs between 2.5.0 and 2.4.x... If, however, the > answer is "tagging 2.5.0 will encourage us to address > those issues" then my question is "Why aren't we doing > that now... for 2.4.x". I am not doing it for 2.4.x, and will continue not to do it for 2.4.x, because I won't contribute to further destabilizing 2.4.x current releases. It takes a serious vulnerability for me to risk the stability of 2.4.x, something on the order of the HTTP conformance issues we faced over the past year. Once again, 4 1/2 year old code had never been shared with the community, once again that ignored code contained defects that would have been noticed in a public -alpha over a four year period. I am for doing this necessary review for 2.5.0, but all the code was reviewed. That's what commit-then-review means. If you failed to review it, you now have a six year knowledge gap and review to conduct. That's not sustainable, nobody at the project has that kind of time. As PMC and committers, we had these commits in our inboxes. We questioned committers about changes that looked incorrect. We vetoed some changes that didn't fit or wouldn't work. It's over-past time for that code, those committers' efforts to see the light of day, even as an alpha for the time being. Any argument to the contrary or new layers of process is disingenuous at best, and obstructionist at worst. > And finally: 2.4.x is now, finally, being the default > version in distros, being the go-to version that people > are using, etc... I would like us to encourage that > momentum. No, 2.4.current is not the default. Our current n.n.n at the time these distributions decided to freeze is the distributed version, then they pick up security backports. RHEL 7 and CentOS 7 are still 2.4.6. Ubuntu 16.04 is still 2.4.7, or 2.4.10 from backports, xenial is 2.4.18 and zesty is 2.4.25 https://w3techs.com/technologies/details/ws-apache/2.4/all 57% of all the deployed httpd 2.4 are one of the first four ancient versions, and 67% if you count 2.4.25 (likely a mix of zesty and non-zesty not updated in 4 months). Of that, 2.4 captures 51% and 49% are older still (2.2/2.0); we can slice those adoption numbers in half. So 1/3rd of httpd deployments are on one of the five versions distributed in these five operating system distributions. Only 11% of the deployments have been refreshed since our June release. If you are talking distributions, they will be at whatever we give them once they ship. They won't pick up our new features until they are ready to tag a new OS release, so 'distros', at least 'os distros' is non sequitur. If you are talking httpd binaries, every creator has their own schema; at Pivotal (and JBoss and similar, I suspect) we prepared to pick up all releases but dropped the ones with quickly identified regressions. Others, like Steffen's or CPanel's, attempt to deliver every httpd release rain or shine AIUI. All of the later will continue on into 2.6.0 or 3.0.0 or 4.0.0. Which OS distributors today are still going to release a new OS on linux kernel 2.x? But let's quantify in terms of actual data. In the time since we forked at Nov 10 2011, httpd 2.x over 1.x grew from 90% to 99% of our user base, 2.0.x legacy fell from 24% to 1%. Of the total webserver footprint IIS fell from 18% to 11%, Apache httpd from 70% to 48%, and ngnix grew from 6% to 36%, eating everyone's lunch. Now this map https://w3techs.com/blog/entry/nginx_reaches_33_3_percent_web_server_market_share_while_apache_falls_below_50_percent explains why this is; Microsoft has been much more proactive in providing a server with documentation to the Chinese market, ngnix to Russian speaking states. But consider in this time period that ngnix, with an API started from scratch (no httpd 0.x legacy there, so little deprecation) has run from 1.1 to 1.13... they also follow an odds/evens schema, so counting only the development releases (our 2.{even}s, we have no stable per se until something hits legacy), that's 6 significant minor releases (multiplied by many subversion releases) to no minor releases at httpd. So while it may be native language support and other good debates between the two technologies, these minor releases obviously caused ngnix no pain, it ships what was then-current in os distributions, and perhaps our unwillingness to release code has contributed to the overall adoption of httpd. Preserving the "2.4.x" designation has won us nothing.
