Actions

Difference between revisions of "Developer Area/Release Instructions/Old Release script"

From Mahara Wiki

< Developer Area‎ | Release Instructions
(Created page with "This documents the steps (formerly on the Release Procedure) that are done by the [http://gitorious.org/mahara/mahara-scripts/blobs/master…")
 
 
(3 intermediate revisions by one other user not shown)
(No difference)

Latest revision as of 01:12, 7 May 2022

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.

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