Developer Area/Release Instructions/Old Release script: Difference between revisions
From Mahara Wiki
< Developer Area | Release Instructions
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
This documents the steps (formerly on the [[Developer Area/Release Instructions|Release Procedure]]) that are done by the [http://gitorious.org/mahara/mahara-scripts/blobs/master/release.sh release script]. | This documents the steps (formerly on the [[Developer Area/Release Instructions|Release Procedure]]) that are done by the [http://gitorious.org/mahara/mahara-scripts/blobs/master/release.sh release script]. | ||
Revision as of 18:18, 12 Mayıs 2011
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
:
- 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 - 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:
- Change
htdocs/lib/version.php
to have a release of X.Y.Z+1testing - Bump the version by 1 again
If doing an unstable (alpha/beta) release:
- Change
htdocs/lib/version.php
to 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.
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