httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: Status for 2.4.20
Date Tue, 29 Mar 2016 06:00:14 GMT
+1

Thanks!

> Am 28.03.2016 um 17:06 schrieb William A Rowe Jr <wrowe@rowe-clan.net>:
> 
> @Everyone on this thread - keep it civil.
> 
>> On Fri, Mar 25, 2016 at 10:13 PM, Noel Butler <noel.butler@ausics.net> wrote:
>>> On 25/03/2016 19:52, Graham Leggett wrote:
>>> On 23 Mar 2016, at 1:58 PM, Noel Butler <noel.butler@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.
> 
> 

Mime
View raw message