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

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.

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