[Linux-ha-dev] Heartbeat Release Strategy

[Andrew Beekhof]

Good morning sports fans.

Over at Heartbeat Central we've been talking and have decided to do  
releases a little differently from now on.

The version numbering will stay the same but we're going to try and  
be a little more formal about what goes into the various releases.

Our current version numbering of X.Y.Z  is usually referred to as  
X := Major, Y := Minor and Z := Point.  While you're of course free  
to call them whatever you like, we're going to think of them in terms  
of their content, ie. Architectural, Feature and Bug releases.


With that in mind, it is our intent that this is what you can expect  
from the Heartbeat team:

Architectural (aka. Major) Releases:
* Contents:    		Architectural changes
* Frequency: 		As required but hopefully not often
* Supported Version:	Current and previous (for a limited period)
* Release Criteria:	5000 CTS Iterations of a 4 node cluster or  
equivalent^

Feature (aka. Minor) Releases:
* Contents:		New features + bug-fixes
* Frequency:		Three releases per year
* Supported Versions:	Current and previous
* Release Criteria:	5000 CTS Iterations of a 4 node cluster or  
equivalent^
* Notes:
   - The timing will probably be March, July and November
   - We may at times decide to skip a feature release, in such cases  
we will make
     an annoucement to this effect
   - Each feature release will have its own (numbered) Hg repository  
on http://hg.linux-ha.org

Bug (aka. Point) Releases:
* Reason:		Urgent bug-fixes and/or new resource agent scripts
* Frequency:		Monthly (providing there are bug-fixes pending release)
* Supported Versions:	Current only
* Release Criteria:	1000 CTS Iterations of a 4 node cluster or  
equivalent^
* Notes:
   - No new features
   - If no new bugs have been fixed we'll just make an announcement  
explaining
     this and not put out a release.
   - Each bug release will be a tag in the Hg repository of it's  
Feature release
   - If every month becomes too much overhead for me, we may move to  
bi-monthly releases

^  eg. an 8 node cluster would need somewhere in the order of 50%  
less iterations to perform an equivalent workload


So, given all that, it is my hope that come March we will be able to  
put out 2.1.0 and from then on follow the above strategy.  We will  
then review this approach every so often to ensure it is still  
appropriate.

regards,
Andrew