Developer Area/Release Policy: Difference between revisions

Latest revision as of 18:29, 27 April 2022

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

@@ Line 1: / Line 1: @@
-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 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 [[Developer Area/Release Instructions|release instructions]] document.
-==Release Types==
+==Release schedule==
-===Alpha===
+See [[6MonthlyCycle]] for details of the Mahara release schedule. See [[SupportedVersions]] for the currently supported Mahara versions.
-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 [http://mahara.org/interaction/forum/index.php?group=1 forums], #mahara IRC channel on freenode or otherwise contacting the developers.
+==Release Types==
-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.
+===Before any releases===
-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.
+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.
-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.
+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===
-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.
+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.
@@ Line 41: / Line 29: @@
 Final releases have the version number X.Y.0 - which may be simplified to X.Y in promotional literature.
-===Point Release===
+===(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.
@@ Line 49: / Line 37: @@
 Good candidates for a point release:
-* security bug
+*security bug
-* bug leading to loss of data
+*bug leading to loss of data
-* regression
+*regression
 Bad candidates for a point release:
-* new features
+*new features
-* change in the UI (i.e. it would invalidate screenshots in documentation and/or books)
+*change in the UI (i.e. it would invalidate screenshots in documentation and/or books)
-* change requiring a database upgrade
+*change requiring a database upgrade
-* usability improvements
+*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 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
+*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.