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
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
