Developer Area/Release Instructions/Old Release script

http://wiki.mahara.org/Developer_Area/Release_Instructions http://gitorious.org/mahara/mahara-scripts/blobs/master/release.sh This documents the steps (formerly on the Release Procedure) that are done by the release script.

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

1. Make sure you have up to date checkouts of both the public and security branches

2. Switch to the public branch and merge the security branch into it

Do not push to the public repository yet.

3. Switch to the security branch and merge the (local) public branch into it

Change to the the appropriate security branch for the branch you're releasing from and run git merge [public-branch] to merge in all the changes. Hopefully there shouldn't be any conflicts.

4. Update the ChangeLog and bump the version

In the branch that you're releasing, add a new dated entry to the ChangeLog file for this release. These bullet points will then be used to write the Freshmeat and FRS release notes.

Change $config->release in htdocs/lib/version.php to the appropriate value. This will be something like 1.0.4, 1.1.0alpha1, 1.1.0beta4 etc.

Change $config->version:

1. If the release is a minor release on the stable branch, e.g. X.Y.Z to X.Y.Z+1, or if the release is an RC, bump $config->version by 1
2. If the release is a major release, e.g. X.Y.Z to X.Y+1.0, OR if the release is an alpha/beta, bump $config->version to YYYYMMDD00

Check everything in and push to the security repo.

5. Tag the release as X.Y.Z_RELEASE

git tag -s X.Y.Z_RELEASE

Enter a commit message of something similar to "1.1.0alpha1 release", then

git push mahara-security X.Y.Z_RELEASE:refs/tags/X.Y.Z_RELEASE

To get the changelog:

git log --pretty=oneline -r oldX.oldY.oldZ_RELEASE..X.Y.Z_RELEASE > ../X.Y.Z_RELEASE.cl

6. Bump the version and release again

If doing a stable or release-candidate release:

1. Change htdocs/lib/version.php to have a release of X.Y.Z+1testing
2. Bump the version by 1 again

If doing an unstable (alpha/beta) release:

1. Change htdocs/lib/version.php to have a release of X.Y.0Z+1dev - e.g. 0.9.0alpha2dev if releasing 0.9.0alpha1
2. Bump the version again (eg YYYYMMDD01)

Check everything in and push to the security repository.

7. Run scripts/build_tarballs.sh

The commit hash is the hash of the commit you made when bumping the version.

scripts/build_tarballs.sh [version]

Run the script without any arguments to see examples of usage. It will build three archives of the tree at the specified tag.

8. Update the public repository

Switch back to the public branch, merge the security branch into it, & push.

9. Sign the tarballs

gpg --armor --sign --detach-sig mahara-X.Y.Z.tar.gz
 gpg --armor --sign --detach-sig mahara-X.Y.Z.tar.bz2
 gpg --armor --sign --detach-sig mahara-X.Y.Z.zip

10. Upload the tarballs

If you have ubuntu lucid or newer you can use the lp-project-upload script:

lp-project-upload mahara X.Y.Z /home/richard/mahara-scripts/mahara-X.Y.Z.tar.gz
 lp-project-upload mahara X.Y.Z /home/richard/mahara-scripts/mahara-X.Y.Z.tar.bz2
 lp-project-upload mahara X.Y.Z /home/richard/mahara-scripts/mahara-X.Y.Z.zip