httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <>
Subject Re: Letting 2.5.x sit idle? [Was: The 'RM' Baton]
Date Wed, 10 Jul 2013 18:18:11 GMT
On Wed, 10 Jul 2013 19:54:00 +0200
Stefan Fritsch <> wrote:

> On Wednesday 10 July 2013, William A. Rowe Jr. wrote:
> > 
> > In practice, 2.2 is the stable release, from what users experience.
> This stems in part from the > 5 years between 2.2 and 2.4. 2.4 simply 
> takes some time to stabilize. 2.2 did so, too (at the company I was 
> working for at the time, we started adoption with 2.2.8 or so).

I think 2.2.4 was the first I found to be usable (or 2.2.3 with lots
of band-aids and bubblegum).  

But what of 2.6?  This was the "wrong thread", again, but if /trunk/
drifts along for 2 years, are we going to have an equally horrid
experience?  Or should we set aside /trunk/ and re-fork it only once 
we are truly committed to putting 2.5.0-alpha in users hands for real
testing, and feedback?

I found these comments from STATUS rather ironic;

 -0.5: sf: I would prefer if this sat in trunk for a few months first
           to receive more testing.

 +0.5: jj: I would prefer if this sat in trunk for a few months first
           to receive more testing.

What testing?  With no (-alpha or -beta) release, there will be few 
(if any) testers.  Only committers.

Heck, why would a user check out /trunk/?  The code they are running
is likely 2.2.x with a hope to upgrade to 2.4.x.  For any real world
user, our /trunk/ is a rather distant place.

So I'd argue that /trunk/ is an unhealthy place right now which does
not have testing.  If we want /trunk/ to become 2.6, we have to start
by releasing 2.5.0-alpha and offering it up to users.  If we don't
believe it's ready, why does it exist at all?  Why not relegate it
to the sandbox and move 2.4.x back to trunk, which it effectively is?

> > The post from the modperl project relayed by Jim this past week is
> > very welcome news, for getting 2.4 adopted by downstream packagers!
> And the other part of the problems is distributions not picking 2.4
> up early because of mod_perl missing and/or because of 2.4 being
> released at an unfortunate point of time in the distribution's own
> release cycle.

Precisely.  With mod_perl, they can pick it up in their next cycle.  It
has been a very long time since 2.4.0, certainly within some of the
bleed releases, but without mod_perl nobody would make the jump.

It isn't inconcievable that 2.4.x is replaced by 2.6.x before any of
the packagers jump up beyond 2.2, and that isn't necessarily a bad
thing, IMHO.

View raw message