Branching and release scheduling

[Manoj Kasichainula]

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