Developer Area/Release Instructions/Release Candidate

From Mahara Wiki

< Developer Area‎ | Release Instructions
Revision as of 17:44, 6 May 2022 by Dianne.tennent (talk | contribs) (Consolidate new dev branch instructions)

Create the new dev branch

Note: You only need to do this for the first release candidate. If you need to do another release candidate, put it on the same branch.

Create a new _DEV branch based off of main.

  • git checkout main
  • git checkout -b 1.10_DEV
  • git push gerrit 1.10_DEV

If Gerrit won't let you push your new branch, you can instead create it through Gerrit.

  • Go to
  • Click on 'Projects', the 'mahara' project, and then on the 'Branches' subtab.

Then do the following

  • In the Makefile of the new _DEV branch, replace main with the name of the branch. Commit and make push.
  • Create an empty 'ChangeLog' file. Commit and make push. Note: the file needs a capital C and L in the name.
  • Update the release in htdocs/lib/version.php to be $config->release = 'XX.XXrc1';

Bump the version on main

  • Go to the main branch and bump the version (e.g. if you just created the 22.04_DEV branch, bump it to 22.10.0dev )
  • In htdocs/lib/version.php update $config->series, $config->release and $config->version (version should be today's date)
  • Update the with information about how to upgrade to this version, e.g. which minimum version they should have etc
  • Commit and make push

Package the release

For a Release Candidate, at this point a zip file will be generated with the Release script and made available on Launchpad for the community to test. This includes a selection of bugs that have been targeted to a the 'rc1' milestone. After the first release candidate, an rc2 milestone may be created to track which ones will go onto the final release. Once an rc1 or rc2 bug has been committed, its status should change back to its original .0 milestone.

At this point, a Release Candidate has been created and goes through testing.

(On the new _DEV branch, follow the usual release instructions up to Sign_and_upload_the_tarballs)== 📋 Final Checks == 🟡 Security team (if you don't have +2 review status, you won't be able to see these patches)

🚨 Make sure that any security reviews/patches are merged before proceeding 🚨

  • Merge the 'Private' security patches.
  • Update the related Launchpad bugs to 'Public security'.

🟡 Release manager

  • CVE #'s - Security issues have an assigned CVE number?
  • Backporting - security fixes backported to all supported versions that need them?
  • Bugs fixed - all bugs going into his release have their fixes merged for all supported versions?
  • Comms - to Mahara partners + drafted the forum posts?

🟡 All devs

  • Confirm your minor point release number, i.e. check the latest minor point release and add 1, e.g. 21.10.4 -> 21.10.5
  • (Security team) Cherry-pick the security bugs with the status ' Confirmed' to your minor point branch. e.g. _DEV
  • Create a release on the milestone on Launchpad to receive the release generated tarballs
  • git pull mahara-scripts
  • Valid GPG - ensure you have a valid GPG key added to your Launchpad account: See
  • lptools - ensure you have the lp-upload-project installed for uploading the release tars: apt-get install lptools

Skip the changelog and release notes

Do not populate the changelog. For the release notes put something like 'First release candidate for 1.4'.

⚡ The release script

  • A git repo will be created at /tmp/mahara.####/mahara/ cloned from .
  • It builds Mahara archives based on the given _DEV branch and puts thme into your current folder. ( .zip, .tar.gz.asc, and .tar.bz2.asc)
  • You will get a script to run later.

Run the script

  1. Go into mahara-scripts and git pull the latest version.
  2. Run ./release.php X.Y.Z X.Y_DEV.
    • X.Y.Z is the new branch that will be made. This is also used in the archive file names.
    • X.Y_DEV is the existing branch we will create the new release from.
    • If the Z in X.Y.Z is "0" this will also create a new _STABLE branch.
  3. When prompted, insert your changelog.

Any data you enter for the prompts will go into the Launchpad release page. You can enter it here, or leave it empty here and enter it directly into the Launchpad webpage.

Check the terminal output in case there are GPG errors

E.g. Tag new version bump commit as 'X.YRC2_RELEASE' error: gpg failed to sign the data error: unable to sign the tag

So this is what I did to fix it, all commands are on command line:

  1. Update the gpg program with: git config --global gpg.program gpg2
  2. Test if it is working with: echo "test" | gpg2 --clearsign

It wasn't so I had to do: export GPG_TTY=$(tty)

then run again echo "test" | gpg2 --clearsign

Run release.php command again and check if it still gives the error.

Do not reboot your machine in the middle of doing a release or you will have to run through the release script again.

Note: For release candidates the commit message should be empty.

✅ Testing

With continuous Behat testing throughout development, we only need to some basic manual testing.

Extract the build and prep the database

Test that we can install Mahara with the pre-built packages.

  1. Extract the build (.tar or .zip) of your pre-built Mahara and make sure you can connect to it via web installer.
  2. Drop the database and create a new blank one.

Test case #1: Install the site with the web interface

  1. Go to your Mahara site and click 'Install'.
  2. Reset your database and repeat with MySQL/PostgreSQL.

Note: If we are doing a .0 release the install will complain about missing $versions->$currentmajorversion->latest release number but don't panic this is because the local copy of the release has the series version that doesn't exist upstream yet so we can ignore this warning·

Test case #2: Manual upgrade with the CLI and the web interface

Web interface

  1. Install a fresh site on version X.Y.Z(-1), i.e. (an earlier version).
  2. Create a portfolio, a blog with a blogpost, a group with a forum and forum post.
  3. Switch the code to your current release.
  4. Check that everything still works.
  5. Go to the site and click 'Upgrade' to get the site version to X.Y.Z .
  6. Repeat with PostgreSQL/MySQL.


  1. Install a fresh site on version X.Y.Z(-1), i.e. (an earlier version).
  2. Create a portfolio, a blog with a blogpost, a group with a forum and forum post.
  3. Switch the code to your current release.
  4. Upgrade to X.Y.Z with the CLI script htdocs/admin/cli/upgrade.php
  5. Check that everything still works.
  6. Repeat with PostgreSQL/MySQL.

🚀 Sign and upload the tarballs

Run ./ to upload the release and clean up any temporary files.

Note I: If running this file stops before completion for any reason you will need to edit it and comment out the bits that did finish so that you don't run those buts twice then try the script again. For example the script does the bit where it pushes the tag to the git remote and signs the zipped files but doesn't upload them - you would need to comment out the 'git push' lines and the 'gpg --armor' lines.

Note II: If the zipped files fail to upload to Launchpad via the script then you will need to manually upload the zipped files and their corresponding .asc files. To do this go to the milestone page in Launchpad and click the 'Add download file' link. Set the description to: release tarball and choose the matching zipped and .asc file to upload. You will need to do this for all the three types: .zip, .tar.bz2, .tar.gz

Creating the new language packs branch

You need to set up launchpad translations for the new branch. See the separate instructions on setting up a new translations branch.

Changelog and release notes

Do not paste the full changelog on Launchpad (that's for the actual release) and only put something like "First release candidate for 1.4" in the bullet point section of the release notes on Launchpad.


Updating however is useful for users who do not have somewhere to set up a test instance but would like to check out the changes.

Do not update the bug tracker

The bug tracker does not need to be updated because no bugs should ever have an RC release as its milestone.

Furthermore, these bugs are not fixed until the release has happened, so they should be left as "Fix committed".

Do not update the demo site

The demo site should always be the last stable release. The RC is not a release yet.


The main purpose of an RC is to get people to test the release for any major bugs. Therefore, we do not consider the RC as a release and only announce it through:

  • Twitter
  • IRC
  • The news forum

(Note that Freshmeat is missing.)

Sample news forum post for first release candidate

Subject: First release candidate for Mahara 1.10 available

We have just published the first release candidate for Mahara 1.10.

This is a call for testing. If you want to make sure that Mahar 1.10 works well on your site, please help us out by testing this first release candidate:

New features for the release candidate are listed on Launchpad with the "nominatedfeature" tag.

We've also done lots of bug fixing is this release cycle. The full list of changes that have been made for 1.10 can be found by clicking here.

If any of the targeted bugs affect your users, this is an opportunity for you to make sure they are fixed properly.

If you find any bugs, please report them on Launchpad so they can be fixed before the 1.10.0 release:

If important bugs are found within the next week we may produce a second release candidate. Otherwise this release candidate will become the final 1.10.0 release.


The 1.10 Release Managers

Sample forum post for second and/or final release candidate

Subject: Second release candidate for Mahara 1.4 available

Based on the feedback we have received so far, this will most likely be the last release candidate before the final 1.4 release:

New Features for the Release Candidate are listed on Launchpad with the newfeature tag:

We've also done lots of bug fixing is this release cycle. The full list of changes that have been made for 1.4 can be found by clicking here.

If you haven't had a chance to test it out yet, please do so now and report any bugs on the tracker:

This is your last chance to make sure your upgrade to 1.4 will be smooth. If nothing major is reported in the next few days, we will be cutting the 1.4.0 release in about a week.


The 1.4 Release Managers