Developer Area/Release Instructions/Release script
From Mahara Wiki
< Developer Area | Release InstructionsRevision as of 17:07, 12 May 2011 by WikiSysop
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 1. Make sure you have up to date checkouts of both the public and security branches
- 2 2. Switch to the public branch and merge the security branch into it
- 3 3. Switch to the security branch and merge the (local) public branch into it
- 4 4. Update the ChangeLog and bump the version
- 5 5. Tag the release as X.Y.Z_RELEASE
- 6 6. Bump the version and release again
- 7 7. Run scripts/build_tarballs.sh
- 8 8. Update the public repository
- 9 9. Sign the tarballs
- 10 10. Upload the tarballs
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.
htdocs/lib/version.php to the appropriate value. This will be something like 1.0.4, 1.1.0alpha1, 1.1.0beta4 etc.
- 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
- 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
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:
htdocs/lib/version.phpto have a release of X.Y.Z+1testing
- Bump the version by 1 again
If doing an unstable (alpha/beta) release:
htdocs/lib/version.phpto have a release of X.Y.0Z+1dev - e.g. 0.9.0alpha2dev if releasing 0.9.0alpha1
- Bump the version again (eg YYYYMMDD01)
Check everything in and push to the security repository.
The commit hash is the hash of the commit you made when bumping the version.
Run the script without any arguments to see examples of usage. It will build three archives of the tree at the specified tag.
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