Developer Area/Release Policy

This document describes the release process for Mahara, from development 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 schedule

See 6MonthlyCycle for details of the Mahara release schedule. See SupportedVersions for the currently supported Mahara versions.

Release Types

Before any releases

Development work on Mahara occurs on the git branch named "master". At the first release candidate for a new major release, a new "STABLE" branch is forked off of master (e.g. "1.8_STABLE"), and the version number in the master branch is incremented (e.g. 1.8rc1dev -> 1.9.0dev). Bug fixes and new features are then committed to the master branch, while only bug fixes (and no new features) should be committed to the STABLE branches.

STABLE branches must maintain a continuous path of upgrades from one commit to the next. Developers should attempt to do this for the master branch as well, but because it is intended primarily for development purposes, if necessary developers may push commits to master that break the upgrade path from previous commits on the master branch.

Release Candidate

When a new major version 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.

(Minor) 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.

The main 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 every bug fix could introduce new bugs. If we're fixing a bug on a stable branch, we think it's important enough to offset the extra bugs it will introduce.

Good candidates for a point release:

security bug
bug leading to loss of data
regression

Bad candidates for a point release:

new features
change in the UI (i.e. it would invalidate screenshots in documentation and/or books)
change requiring a database upgrade
usability improvements
fix for something that didn't work in the last release either (i.e. it's not a regression, it simply has never worked and we just haven't fixed it yet)
fix for a minor bug

Note that these are not strict rules but rather guidelines that are helpful in keeping with our main goal of minimizing changes on the stable branch.

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

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.

Branching

A code branching map that reflect the release policy is generated on launchpad: https://launchpad.net/mahara/+series