Developer Area/Version Numbering Policy
From Mahara Wiki
< Developer AreaRevision as of 18:40, 9 May 2011 by WikiSysop (Created page with "This page documents the Mahara version numbering scheme, and how the version numbers of new releases are decided. <div id="section_1"> == Stable/Unstable Versions == Mahara ha…")
This page documents the Mahara version numbering scheme, and how the version numbers of new releases are decided.
Mahara has a stable and unstable release. The stable release is what you should use for production Mahara installations. Stable releases do not change much, mainly receiving bug fixes.
Unstable releases are previews for what will be in the next major iteration of Mahara. You should not use unstable releases on production websites, but you are welcome to try them out to see what new features will be in the next release.
Like Debian, Ubuntu and some other software, Mahara releases have code names, as documented in the release policy.
Stable versions are numbered X.Y.Z. As of the writing of this section, Mahara is at
1.0.6, this version number will be used for the examples that follow.
Unstable is defined as "The HEAD of the master git branch". It is generally signaled by either an increased X or Y in the version number. For example, when the latest stable version was 1.0.6, unstable was heading towards Mahara 1.1. Releases of unstable have version numbers like 1.1.0alpha3 or 1.1.0beta1.
How the Release Version Changes
Imagine the current stable version is 1.0.6. In git,
lib/version.php will contain '1.0.7testing'. Bug fixes will be made from time to time here.
At the point when a release is ready, the version in
lib/version.php will be changed to 1.0.7, the release made and the version changed again to 1.0.8
Currently, master has 1.1.0beta3
dev. When we branch for 1.1,
lib/version.php on that branch will be changed to 1.1.0rc1dev, while trunk will be bumped to
The 1.1 branch will be testing until its first release (1.1.0), then we repeat as for the 1.0 branch.