+1 Thanks!
> Am 28.03.2016 um 17:06 schrieb William A Rowe Jr <wr...@rowe-clan.net>: > > @Everyone on this thread - keep it civil. > >> On Fri, Mar 25, 2016 at 10:13 PM, Noel Butler <noel.but...@ausics.net> wrote: >>> On 25/03/2016 19:52, Graham Leggett wrote: >>> On 23 Mar 2016, at 1:58 PM, Noel Butler <noel.but...@ausics.net> wrote: >>> >>>> as stated previously, this shit will happen when certain people push with >>>> a release often mentality >>>> >>>> AFAIK there is *ZERO* critical exploit bugs to be patched by any pending >>>> release, so lets get house in order S T A B L E , then worry about >>>> releases, jesus christ, we are not ubuntu or redhat with set programs to >>>> release every 3 or 6 months regardless if shit is ready or not….. >>> >>> It sounds like you’re making drama where there is none. >> >> sounds like you only look at this from one perspective, and thats not of the >> users, especially, the larger users. > > Precisely the point. If httpd were commercial software, there would only be > one perspective, that of the largest users with fairly static deployments that > demand very small deltas - those that ensure few if any regressions. Smaller > or more nimble users who need the most recent features are neglected in that > scenario. > > Instead httpd does not operate as commercial software, it is open source. > When it breaks, you get to keep (and patch) all the pieces. That's the origin > story of this software and our continued model for success. No amount of > pleas that "it shouldn't be that way" are going to change the mindset of the > project participants. Please remember you are a guest on this list. > > When we decided during 1.3.x that things were so shaky (third party module > recompilation was frequently necessary during the early 1.3.0-1.3.14 versions) > that we could do better for user communities. > > Therefore, when we released 2.0 as GA, we declared the ABI stable, and > proceeded on ABI and API breaking work on a 2.1-dev trunk branch. We all > agreed that 2.1 wouldn't be GA, but we would release 2.2.0 once we believed > that branch was ready to be ABI-stable. That model continues to this day, > breaking changes are on 2.5-dev in trunk, and we seek 100% compatibility > on the 2.4.x branch. There were contentious discussions that led us to this > model, but it was driven by competing interests by the developers of this > project, who are also users --- as opposed to external "demands". > > We will seek to continue to release early and often, and one of our current > faults is that we haven't been releasing 2.5-dev often enough to engage users > in the next release series, but pouring most of our energy into wedging these > changes back into the 2.4.x branch. But unlike commercial software and > many OSS projects, we don't declare 2.4.0 to be "feature complete", and > we continue to improve it in straightforward ways throughout the 2.4 lifetime. > > If you want to package a stable "product", you can follow the RedHat and > others' model. Just to take that single example, httpd 2.4.3 is the released > flavor by RedHat. They go to the extra effort to backport fixes-only and plan > to support that version for some 10 years or so. That is why many larger > users choose to stick with something like RHEL or CentOS or similar > distributions which are feature-frozen and much more stable than an active > product undergoing constant enhancement. > > Just to wrap up another tl;dr post... others offered you a different option, > skip those versions which are too "experimental" for your tastes, and wait > for bugs to shake out. We assert that 2.4.newest is the best available > version, but in such a large, modular and flexible project, it's impossible > to assure that a change set (release) will be an improvement for each and > every use case. > > Use the version that is most appropriate to your use case, and seek a > commercial product if you expect the sort of stasis that your protest > appears to seek. > >
