Developer Area/Release Policy

This document describes the release process for Mahara, from alphas through to the final, stable release of a new major version and releases of minor versions.

This is a policy document, not procedure. Specific procedures are documented in the release instructions document.

Release Types

Alpha

Alphas are designed to get early feedback on new features that will be in the next major release. It is expected that the new features may not be complete, but they should be a very good portion of the way there. Because bugs are likely and expected, bug reports are discouraged during this time. However, high level feedback about the overall feel of any new features is encouraged, and can be communicated through the forums, #mahara IRC channel on freenode or otherwise contacting the developers.

Alpha releases are made at a point when much or all of the major functionality for a release has been merged to trunk from the appropriate topic branches. Such releases do not have to have an upgrade path, but should install successfully from scratch.

There may be just one, or several alphas, depending on the features involved, how fast the codebase is moving, or other factors.

By the end of the alpha phase, all major functionality should be feature complete and merged to trunk. Furthermore, an upgrade path should be in place to upgrade from the existing stable release to trunk.

Beta

Betas are designed to provide a period in which the code base is stabilised before a release, and give enterprising end users a chance to experiment with and report bugs on the new features. Bug reports are expected, and should be reported against trunk on the tracker.

In the beta phase, focus turns to bug fixing, testing, documentation and translating. It should be possible to upgrade from the existing stable release to the beta, so that the upgrade path may be tested. No new language strings should be added after the first beta, to aid translators.

There may be one or several betas, depending on how long the codebase takes to stabilise. Betas should be released on a regular schedule, anywhere from weekly to monthly, depending on the size and number of features being tested for the release. It is not expected that users should be able to upgrade from one beta to another, from any alpha to the beta, or from any beta to the next stable release.

During the beta period, fixing of other miscellaneous bugs on the tracker should be undertaken. Test cases for any bugs fixes, as well as test suites for new functionality should be written. Documentation should be written, both for developers and end users.

By the end of the beta phase, all bugs should be fixed or accounted for, and an upgrade from the existing stable release to trunk should be successful. Translations should be completed.

Release Candidate

At the point when a beta is considered ready for release, a release candidate should be made. It is expected that if no showstopping bugs are found in the release candidate, the stable release will immediately follow. The first RC is where the release is branched.

If a bug is found and judged worthy of fixing, another release candidate should be made with a fix. Such release candidates should be made and released as soon as possible after an issue is found.

If no major bugs that have a noticable negative impact on the release are found in a release candidate for three days, then the release candidate is used to make the release.

Final Release

The final release should contain the same code as the last release candidate, and is made available for general download. End users can expect a successful upgrade from the previous stable release to this version. A version will be created in the bug tracker for this release and bugs should be reported against this version.

Final releases have the version number X.Y.0 - which may be simplified to X.Y in promotional literature.

Point Release

Point releases are made after important bugs identified in the current stable release are fixed. The time at which any given point release will be made will vary depending on the number and severity of bugs fixed.

No new features should be added to a point release.

The idea is that everybody should be upgrading to the latest point release since they may contain security fixes. Therefore, it's important to limit as much as possible the number of changes on the stable branch since a bug fix can often introduce new bugs.

Point releases have the version number X.Y.Z, where Z is > 0.

Codenames

Major Mahara releases will have code names. The schema for code names is Harry Potter spells. The unstable release is always known as Cruciatus.

The stable 0.9 release is known as Accio, 1.0 is known as Alomohora and 1.1 is known as Sonorus.

Language Packs

By the time of the first release candidate, the language packs that are going to be made available with the release will be complete in revision control. At the time of the final release, they should all be tagged and built.

Language packs could, in theory, be completed at any point after the last beta, even after the final release, and made available the moment they are complete.

Plugins

Plugins can follow their own version numbers - they are not tied to the Mahara version. They should still follow the version policy however.