httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: Status for 2.4.20
Date Mon, 28 Mar 2016 15:06:20 GMT
@Everyone on this thread - keep it civil.

On Fri, Mar 25, 2016 at 10:13 PM, Noel Butler <>

> On 25/03/2016 19:52, Graham Leggett wrote:
>> On 23 Mar 2016, at 1:58 PM, Noel Butler <> 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
demand very small deltas - those that ensure few if any regressions.
or more nimble users who need the most recent features are neglected in that

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
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
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
in the next release series, but pouring most of our energy into wedging
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

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
flavor by RedHat.  They go to the extra effort to backport fixes-only and
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.

View raw message