httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Strauss <gs-apache-...@gluelogic.com>
Subject Re: Branching and release scheduling
Date Wed, 17 Nov 2004 02:32:49 GMT
On Tue, Nov 16, 2004 at 06:34:36PM -0700, Brad Nicholes wrote:
> I have to agree with Jim.  Well put!

And I concur, too.

> >>> jim@jaguNET.com Tuesday, November 16, 2004 5:55:04 PM >>>
[...]
> I find it somewhat hard to get "excited" by 2.x development because
> 2.1 almost seems like a black hole at times... You put the energy
> into the development but have to wait for it to be folded into
> an actual version that gets released and used. Now waiting is
> good, but sometimes it seems that the backports are slow in getting
> approved. I think most developers like, well, if not *immediate*
> satisfaction, something more quick than the current 
> develop-2.1-and-wait-
> for-a-long-time-before-folded-into-2.0.
> 
> Stability is great, but we should be careful that we don't "unduly"
> sacrifice developer energy. This may not be so clear, so feel free
> to grab me :)

Having "stable" releases too often is a burden on admins who need
to test, qualify, and roll-out new versions.  

At the same time, having HEAD languish in svn too long without
critical mass of testers takes the steam out of HEAD because
people will invest more energy in the stable branch.

Now, I think even (stable) and odd (development) sequences are goodness.

I would like to additionally suggest a release schedule for "stable"
along the lines of OpenBSD's semi-annual release.  That way, people
can develop towards the next release instead of working on stable
and playing catch-up each major release.

About two months before the next "stable" release is estimated,
feature-freeze is set and any new features that have not established
themselves as stable will not make it into this stable branch.
Having such a release schedule will hopefully expand the testing
community because large companies will now be invested in testing
a known quantity with a known (estimated) release.

None of this precludes a 2.2 branch which may include an incompatible
API (hopefully with limited impact), or a 3.0 branch with wider API/ABI
consequences.

Cheers,
Glenn

Mime
View raw message