@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.
