Developer Area/Release Instructions

This document details the procedure to follow when building a release for general download. Other documents related to this one include the Version Numbering policy and the Release Policy.

For the purposes of these instructions, assume we are releasing version X.Y.Z of Mahara.

Also see these pages for more instructions:

• Major release
• Release candidate

Pre-requisites:

• You must have a valid GPG key and you need to add it to Launchpad (see https://launchpad.net/~username/+editpgpkeys).
• You must have lp-upload-project installed:

 apt-get install lptools

OLD INFORMATION - please ignore

• Configure lptools to write public information on Launchpad on your behalf:

manage-credentials create -c ubuntu-dev-tools -l 2

(Note: This won't work for Ubuntus after Maverick, as manage-credentials appears to have gone away. You will need to install lptools to proceed with the script usage.)

1. Make sure your mahara-scripts checkout is up to date

You need to have an up-to-date version of the mahara-scripts repo in order to get the latest copy of the release script. That's the only repo you need to have since the release script will clone the git.mahara.org repo all by itself.

2. Run the first part of the release script

IMPORTANT !!!

Make sure that any security reviews/patches are merged before proceeding. THESE PATCHES ARE MARKED STATUS: Draft. If you do not have the ability to see the security patches - ask someone on the security team to merge them for you.

Using the script you got in the previous step, run the first step of it like this:

./release.php X.Y.Z X.Y_STABLE

This will create tarballs as well as a changelog and some release notes to paste into Launchpad. It will also spit out another script (release-X.Y.Z-cleanup.sh) to be run later.

Note that the repos that will be pushed back to git.mahara.org are live in your /tmp. Do not reboot your machine in the middle of doing a release or you will have to run through the release script again.

3. Testing

As we do continuous behat testing throughout development we only need to do the basic manual testing. Here is the testing that needs to be done using the tarballs you generated in the last step:

1. untar the tar that release.php generated somewhere and make sure you can connect to it via web installer
2. drop the db and create a new blank one to test install

The install should be run 4 times, both on MySQL and Postgres and both via the web interface and CLI script.

Once we are all happy with that we need to run these manual upgrade tests:

1. install a fresh X.Y.Z-1 site, then upgrade to Z.Y.Z on Postgres, via web interface, and quickly check that everything works (create a portfolio, a blog with a blog post, a group with a forum and a forum post)
2. repeat that last step on MySQL

4. Create the release on Launchpad

Go to https://launchpad.net/mahara/+milestone/X.Y.Z

First move any bugs that are not going to be part of this release to the next milestone in the series, eg if this is X.Y.3 then move to X.Y.4. You may need to make the milestone if it doesn't already exist via https://launchpad.net/mahara/X.Y and using the 'create milestone' link.

Then click on "create release" and give it today's date.

Leave "Keep the X.Y.Z milestone active." unchecked.

Paste in the release notes and the changelog that were generated for you by the release script. You can remove the "bump version number" commits from the changelog since they aren't very useful :)

5. Sign and upload the tarballs

Run the next part of the release script, i.e. the script that was spit out by the release script.

./release-X.Y.Z-cleanup.sh

You will be prompted for enter release notes and a changelog. This will happen once for each archive file that is being uploaded, so you'll see six prompts total. Any data you enter here will go into the Launchpad release page. So, you can either enter it here, or leave it empty here and enter it directly into the Launchpad webpage.

6. Update bugs on the tracker

On Launchpad, click on all of the bugs targeted for that milestone and move them from "Fix committed" to "Fix released".

Now is also a good time to create the next release number in the series. Any remaining bugs that were not fixed for this release may be transferred to the next one, if they're still on the roadmap but were simply delayed.

7. Put the release notes on the wiki page

This is just adding a link to the right page on Launchpad, we no longer have a duplicate copy of the release notes on the wiki.

Release notes page

8. Language packs

Create a new translation branch on launchpad.net and update the language scripts for the new release so that they appear on http://langpacks.mahara.org

9. Security forum posts

If this release includes security fixes, then publish advisories on the security forum.

Here's a sample forum post:

Title: Security issue relating to (Category) <1.0.5, <1.1.3, <1.2.0

<description of issue>

Category: (XSS, Access control, Privacy, Spam, Privilege escalation, Session fixation, Etc.)
Severity: (Critical, High, Medium, Low)
Versions affected: <1.0.5, <1.1.3, <1.2.0
Reported by:
Bug reports: (launchpad URL)
CVE reference: (If you have one; if not, this can be added later) 

Sticky: No
Closed: No

It can be tricky to decide what to put down for "Category". This should be the "category" in the security sense (like a category on the OWASP site) rather than category of Mahara functionality. Some categories we have used in the past:

• Injection
• Password security
• Cross-site scripting (XSS)
• Cross-site request forgery (CSRF)
• Access control (i.e., users being able to bypass content sharing permissions)
• Privacy (i.e., we tell a user that a piece of information is private but then we accidentally display it publicly)
• Session fixation
• Privilege escalation
• Disclosure of system information
• Stored XSS
• Session management
• User Authorization

10. News forum posts

Post announcement in the news forum at http://mahara.org/

Include links to the security advisories and a link to the download page on Launchpad.

Now is a good time to notify translators about changed strings, if this is a stable release. I tend to do this with a forum post in the Translations forum.

Here is a sample minor release announcement:

Title: Mahara security release: 15.04.1, 1.10.4, 1.9.6

Hi all,

Today we're announcing new minor releases for the Mahara 15.04, Mahara 1.10, and Mahara 1.9 series.

These releases include <X> security fix<es> relating to <list of issues>, as well as several bug 
fixes. Site administrators are advised to upgrade as soon as possible.

Release packages, as well as a full list of changes, are available on our Launchpad project:

   15.04.1: https://launchpad.net/mahara/+milestone/15.04.1
   1.10.4: https://launchpad.net/mahara/+milestone/1.10.4
   1.9.6: https://launchpad.net/mahara/+milestone/1.9.6

<if this is the last release for a series:>
Note: the 1.9.6 release is the last supported release in the 1.9 series. 

Special thanks, as always, to everyone who helped by reporting bugs, submitting patches, and testing 
the changes!

Sticky: No
Closed: Yes

11. Quick announcements

• Create a topic in the Mahara news forum (and security forum if it's a security release) - see below for more information.
• Change the topic of #mahara and include a link to forum topic on #mahara-dev
• Put a note on:
  • Twitter
  • freecode (formerly Freshmeat)
  • LinkedIn
  • Facebook MUG, Mahara DE, Moodle-Mahara Meetup, Mahara in Japanese

You may need to ask a previous release manager to get access to some of these accounts.

12. Update the demo.mahara.org install (currently Catalyst hosted)

demo.mahara.org is deployed using Catalyst's standard internal hosting deployment scripts. Also update the installed language packs. As a guideline, language packs that are 90% or more translated should be installed.

Subpages

• Creating a GPG key
• Release script