Heartbeat Release Procedures
The heartbeat program is one of the core components of the
Linux-HA (High-Availability Linux) project.
The Linux-HA project is much more than heartbeat, but it is a core component
of the project.
This page describes the procedures which we follow before releasing a
new stable version.
- Declare a base feature freeze
- Provide fixes to critical bugs
- Test the CVS version
- Produce an unstable release from CVS
- Release the unstable version and ask for comments
- If bugs are reported, repeat from step 2
- If bugs are reported, repeat the request for comments
- Audit and update the ChangeLog in the Specfile
- Release the Stable version
1. Declare a base feature freeze
A Base Feature Freeze is a freeze of features to the base code.
Features which only involve adding new optional dynamically loaded modules
may be permitted according to the judgement of the integrator.
2. Provide fixes to critical bugs
Produce a list of bugs which have to be fixed before the relase, and fix them.
It is not necessary to fix them all in order to release an unstable version.
3. Test the CVS version
Use the CTS code to test the cluster.
500 iterations is normally desired before releasing an unstable relase.
4. Produce an unstable release from CVS
To produce the unstable release, follow these steps:
- Change the VERS string in the top level makefile.
- Perform a "make rpm"
5. Release the unstable version and ask for comments.
- Perform a "make handy"
- Modify the unstable release information in the
ha-web/download/index.html file.
- Issue an ha-update command to push the release out the web site
- Announce the new release to the linux-ha and linux-ha-dev mailing
lists, asking for comments on the new release.
- Announce it on freshmeat.
6. If bugs are reported repeat from step 2
7. If bugs aren't reported, reissue request for comments, and perform thorough testing.
The normal waiting time should be at least 2-3 days, or longer if holidays
are involved.
Thorough testing consists of at least 5000 iterations without Stonith and
at least 500 iterations using Stonith.
8. If bugs are reported repeat from step 2
9. Audit and update the ChangeLog in the Specfile
Examine the ChangeLog and make sure all recent bug fixes were put into it.
Normally this should be updated incrementally as development proceeds, so
this step should be short and simple.
10. Release the Stable version
- Change the VERS string in the top level makefile.
- Perform a "make rpm"
- Perform a "make handy"
- Modify the stable release information in the
ha-web/download/index.html file.
- Issue an ha-update command to push the release out the web site
- Announce the new release to the linux-ha and linux-ha-dev mailings
and CC the LWN.
- Announce the new release on freshmeat.
Things which currently need manual testing:
- restart -r testing - including client children.
This should include quick and "slow" restarts
- General client API testing
- A few iterations of testing under flood pings...
- nice_failback vs not nice_failback testing
- Split brain testing.
- STONITH "niceness": nice and non-nice failback.