Branching and release scheduling

[Manoj Kasichainula <ma...@io.com>]

We had a good discussion over lunch today on our release processes and 
how to have stable releases while making new feature development as fun 
and easy for the geeks as possible.

The main branch is always the development branch, with new features 
added whenever people see fit. There is never a feature freeze or even 
development slowdown on this branch. There should be regular releases 
based on this, roughly every couple of weeks, but basically whenever 
anyone is in the mood to roll a tarball. But there really needs to be a 
good script for rolling a tarball easily and quickly.

These tarballs get full fledged announcements on the website. They get 
odd-minor-version releases, e.g. 2.1.x while the latest stable branch is 
at 2.0.x. They are only alphas, with no commitment to ABIs, APIs, or 
suitability for anything.

Whenver there is consensus that it's time to get a release out soon, we 
make a branch. The branch is in feature freeze for its entire lifetime, 
The branch is named for the stable release it will eventually be. So for 
example, we could branch during the 2.1.x, decide that the feature set 
merits a 2.2 version number, and name the branch "2.2". As long as the 
releases on that branch are considered unstable, releases are still 
labelled 2.1.x. Once the release is deemed good enough for general use 
and the ABI is stable, it gets labelled 2.2.0. Further releases on that 
branch are naturally labelled 2.2.1, 2.2.2, etc.

I think I included all the appropriate details, but the picture is 
probably clearer. Rich Bowen took it, and I moved it to save his 
bandwidth: http://www.apache.org/~manoj/dscn2804.jpg

Re: Branching and release scheduling

[Jim Jagielski <ji...@jaguNET.com>]

On Nov 16, 2004, at 3:16 PM, Manoj Kasichainula wrote:

> We had a good discussion over lunch today on our release processes and 
> how to have stable releases while making new feature development as 
> fun and easy for the geeks as possible.
>

The is a purely personal POV, and I'm wishing I was at the lunch because
this addresses something that I've been think and maybe others as well,
considering a similar Email thread I see from Brad N, so take the below
as my own opinions.

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 :)

Re: Branching and release scheduling

[Manoj Kasichainula <ma...@io.com>]

On Tue, Nov 16, 2004 at 06:16:18PM -0500, Me at IO wrote:
>I think I included all the appropriate details, but the picture is 
>probably clearer. Rich Bowen took it, and I moved it to save his 
>bandwidth: http://www.apache.org/~manoj/dscn2804.jpg

I missed discussing how APR fits in this scheme. The main dev branch 
would build against reasonably updated HEAD versions of APR. Given group 
consensus, we could stick to tags or branches of APR if needed.

On the stable branch, the tree should be moved from this state to 
supporting a released version of APR.

Roy raised some concerns about not being able to track versions of APR 
with the fixes we need. The APR guys say that everyone with httpd commit 
can get APR commit if needed, so that solves part of the problem, but I 
wonder if those httpd committers can drive APR releases.