Heartbeat roadmap

This page tries to describe the roadmap for the next upcoming versions of heartbeat and their dates. The easy part is describing the policy and roadmap for the STABLE release series 1.0 and 1.2, and then the major release 2.0 we are working towards will be described.

This page is meant to complement the HeartbeatBugzilla page to help you understand which version number you should file a bug or enhancement request against.

LarsMarowskyBree adds that this is tentative and not yet fixed. Feedback is welcome!

heartbeat 1.0 + 1.2

Both these releases are in maintenace mode only; no new features are expected to be added to them.

Before reporting a bug, please always upgrade to the latest version of the stable series and reproduce the bug there. In almost every case, upgrading to the latest 1.2 release is suggested for current users of 1.0.

Please report the bug against the version you are seeing it on (surprise!). The pre versions are to document issues in the CVS branches preceeding the next respective stable release in that series.

Releases in the stable series are on a as-needed basis; when enough issues have accumulated to warrant a new release, we will do one.

For 1.0, only severe bugs or security incidents will trigger a release.

Heartbeat 2.0

As explained in the HeartbeatBugzilla page, we use Bugzilla to track which features are going to be implemented in which version and by whom.

This table describes the proposed roadmap and the expected key features:

(Again, in particular the key features are totally pulled out of the blue.)

The roadmap splits into four distinct phases:

Alpha

Releases are those with the most active development and features being added. During this phase, we still expect some design changes. Stability is not yet the most important feature in the beginning, but becomes more important towards the end.

After this phase, the core of the new heartbeat system (CRM, LRM, heartbeat itself) should be functionally complete for the 2.0 release already.

(LarsMarowskyBree would like to up the version number from 1.3 to 1.99 to make it clear we are working towards a 2.0 release as opposed to 1.4.)

Beta

During the beta-phase, we focus on stabilizing the core. No new major features which would require restructuring the core will be added as a rule. (Unless of course they are needed to fix a major short-coming, but you get the idea.)

Features which could still be added here are documentation, resource agents, new tests et cetera.

After the beta phase, we should be complete both in the core and tests as well as the peripherals.

Release candidates

This phase is dedicated to testing and putting it all through the paces. The number of release candidates is just a guess; maybe RC1 is all we need to call it golden.

No new features, only bugfixes will be accepted (after being reviewed by at least two developers).

General-Availability

The 2.0.0 release with all the new goodness should be released around the end of February 2005.

Deferred features or the 2.1 series

Features which we cannot put into 2.0 due to time constraints should be assigned to the 2.1 version place holder so they don't get lost. We will work out a finer grained versioning scheme as soon as we start working on the next release.

2.1 will be the next development cycle, working towards a 2.2 stable release eventually, but maybe we can even backport features to 2.0 as soon as they have stabilized in 2.1. We shall see.

Features that need to be slotted into the schedule

• SUSE YAST GUI
• Non-YAST GUI
• GFS integration

Linux-HA site built by the Linux-HA crowd. HTML4 / CSS2