|
|
| (109 intermediate revisions by 12 users not shown) |
| Line 1: |
Line 1: |
| http://wiki.mahara.org/Developer_Area/Version_Numbering_Policy
| | Mahara creates 2 major releases per year (April: XX.04.0, and October: XX.10.0). We also create 'minor point' releases when we need to add urgent fixes and security updates (e.g. XX.04.1, XX.04.2 etc). Doing minor point releases is slightly different to doing a major release. On a major release, we apply any security and bug fixes that are included in the release as a minor point ''update'' to other supported versions. Minor point ''releases'' are for security fixes or urgent bug fixes - these happen between major releases. |
| http://wiki.mahara.org/Developer_Area/Release_Policy
| |
| http://wiki.mahara.org/Developer_Area/Release_Instructions/Creating_a_GPG_key
| |
| https://launchpad.net/~username/+editpgpkeys
| |
| http://gitorious.org/mahara/mahara-scripts
| |
| http://gitorious.org/mahara/mahara-scripts/blobs/master/release.sh
| |
| http://seleniumhq.org/projects/ide/
| |
| https://launchpad.net/mahara/+milestone/X.Y.Z
| |
| https://bugs.launchpad.net/mahara
| |
| http://wiki.mahara.org/Release_Notes
| |
| http://freshmeat.net/projects/mahara
| |
| http://mahara.org/interaction/forum/view.php?id=43
| |
| http://www.mahara.org/
| |
| https://launchpad.net/mahara/+download
| |
| This document details the procedure to follow when building a release for general download. Other documents related to this one include the [[Developer Area/Version Numbering Policy|Version Numbering policy]] and the [[Developer Area/Release Policy|Release Policy]].
| |
|
| |
|
| For the purposes of these instructions, assume we are releasing version X.Y.Z of Mahara.
| | ==Overview== |
| | {| class="wikitable mw-collapsible" |
| | !'''STAGES''' |
| | !'''Release Candidate''' |
| | !'''Major release''' |
| | '''(XX.XX.0)''' |
| | !'''Minor point release''' |
| | '''(XX.XX.1 etc)''' |
| | |- |
| | |'''1. Release prep''' |
| | |RC Prep |
| | |'''[[Developer_Area/Release_Instructions/Pre-release|Major Prep]]''' |
| | |Minor Prep |
| | |- |
| | |'''2. The Release''' - Outcome: zip file is on Launchpad (a major release + 3 minor points) |
| | |'''[[Developer_Area/Release_Instructions/Release_Candidate|RC Release]]''' |
| | |'''[[Developer_Area/Release_Instructions/Release_day|Major Release]]''' |
| | |[[Developer Area/Release Instructions/Minor Release|'''Minor Release''']] |
| | |- |
| | |'''3. Release follow-up admin''' - forums, bug report updating, admin etc |
| | |'''[[Developer_Area/Release_Instructions/Release_Candidate_Follow_Up|RC Follow up]]''' |
| | |✅ |
| | |✅ |
| | |- |
| | |'''4. Community site upgrades''' |
| | |NA |
| | |✅ |
| | |NA |
| | |- |
| | |'''5. Minor point updates''' for all supported versions and clients who have paid for that support package |
| | |NA |
| | |✅ |
| | |✅ |
| | |- |
| | |'''6. Retro workshop''' |
| | |NA |
| | |✅ |
| | |NA |
| | |} |
|
| |
|
| <font color="rgb(128, 0, 0)">''Note: for major releases, there are a few more steps (like creating the X.Y_STABLE branch and writing really good release notes).''</font>
| | ==Links to documentation== |
|
| |
|
| <div id="section_1">
| | #A week before the release: [[Developer Area/Release Instructions/Comms|Comms]] |
| | #[[Developer Area/Release Instructions/Pre-release|Pre-release steps for developers]] |
| | #[[Developer_Area/Release_Instructions/Release_day|Release day steps for developers]] |
|
| |
|
| ====Pre-requisites:==== | | ====Extra info for devs==== |
|
| |
|
| * You must have a [[Developer Area/Release Instructions/Creating a GPG key|valid GPG key]] and you need to add it to Launchpad (see https://launchpad.net/~username/+editpgpkeys). | | *[[Developer_Area/Release_Instructions/Creating_a_GPG_key|Creating a GPG key]] |
| * You must have lp-upload-project configured to '''write public information''' on Launchpad on your behalf: | | *[[Developer Area/Version Numbering Policy|Version Numbering policy]] |
| | *[[Developer Area/Release Policy|Release Policy]] |
|
| |
|
| manage-credentials create -c ubuntu-dev-tools -l 2
| |
|
| |
|
| <div id="section_2">
| | '''OLD DOCUMENTATION (Beware: only kept for posterity)''' |
|
| |
|
| ===1. Make sure your mahara-scripts checkout is up to date===
| | *[[Developer Area/Release Instructions/Old Major Release|Old Major release]] |
| | *[[Developer Area/Old release Instructions|Old release instructions]] |
| | *[[Developer Area/Release Instructions/Old Release script|Old Release script]] |
|
| |
|
| You need to have an up-to-date version of the [http://gitorious.org/mahara/mahara-scripts mahara-scripts] repo in order to get the latest copy of the [http://gitorious.org/mahara/mahara-scripts/blobs/master/release.sh release script]. That's the only repo you need to have since the release script will clone the gitorious repo all by itself.
| | [[category:Developer Area]] |
| | |
| </div><div id="section_3">
| |
| | |
| ===2. Run the first part of the release script===
| |
| | |
| Using the script you got in the previous step, run the first step of it like this:
| |
| | |
| ./release.sh X.Y.Z X.Y_STABLE
| |
|
| |
| | |
| <br /> 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 gitorious 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.
| |
| | |
| </div><div id="section_4">
| |
| | |
| ===3. Testing===
| |
| | |
| Here is the testing that needs to be done using the tarballs you generated in the last step:
| |
| | |
| # install the [http://seleniumhq.org/projects/ide/ Selenium firefox plugin] if you don't already have it
| |
| # untar the release you want to test somewhere and make sure you can connect to it and login as admin
| |
| # check the right branch out (X.Y_STABLE for X.Y.Z)
| |
| # cd test/selenium/ && ./generate-testsuites.py
| |
| # in firefox: Tools | Selenium IDE
| |
| # in Selenium: File | Open Test Suite
| |
| # open test/selenium/TestSuite.html
| |
| # set the Base URL to where you can connect to that Mahara site
| |
| # drop the db and create a new blank one (the selenium tests start by running the install)
| |
| # hit the "play entire test suite" green "play" button.
| |
| | |
| The test suite should be run both on MySQL and Postgres. Then run these manual upgrade tests (no need to run the Selenium test suite):
| |
| | |
| # install a fresh X.Y.Z-1 site, then upgrade to Z.Y.Z on Postgres and quickly check that everything works (create a portfolio, a blog with a blog post, a group with a forum and a forum post)
| |
| # repeat that last step on MySQL
| |
| | |
| </div><div id="section_5">
| |
| | |
| ===4. Create the release on Launchpad===
| |
| | |
| At https://launchpad.net/mahara/+milestone/X.Y.Z
| |
| | |
| 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 :)
| |
| | |
| </div><div id="section_6">
| |
| | |
| ===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
| |
| | |
| <br /> When prompted by lp-project-upload for release notes and a changelog, don't enter anything there since you've already put them on Launchpad in the last step. You will be prompted twice for each file upload (6 times in total).
| |
| | |
| </div><div id="section_7">
| |
| | |
| ===6. Update bugs on the tracker===
| |
| | |
| On [https://bugs.launchpad.net/mahara Launchpad], click on all of the bugs targetted for that milestone and move them from "Fix committed" to "Fix released".
| |
| | |
| </div><div id="section_8">
| |
| | |
| ===7. Put the release notes on the wiki page===
| |
| | |
| [[Release Notes|Release notes page]]
| |
| | |
| </div><div id="section_9">
| |
| | |
| ===8. Quick announcements===
| |
| | |
| * Change the topic of #mahara
| |
| * Put a note on Twitter and Identica.
| |
| * Update [http://freshmeat.net/projects/mahara freshmeat] to report the new release
| |
| | |
| You may need to ask a previous release manager to get access to some of these accounts.
| |
| | |
| </div><div id="section_10">
| |
| | |
| ===9. Security advisories===
| |
| | |
| If this release includes security fixes, then publish the advisories on the [http://mahara.org/interaction/forum/view.php?id=43 security forum].
| |
| | |
| </div><div id="section_11">
| |
| | |
| ===10. Update the news at [http://www.mahara.org/ http://mahara.org/]===
| |
| | |
| Posting in the news forum does this.
| |
| | |
| Include links to the security advisories and a link to the [https://launchpad.net/mahara/+download 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.
| |
| | |
| </div><div id="section_12">
| |
| | |
| ===11. Update the demo.mahara.org install (currently Catalyst hosted)===
| |
| | |
| demo.mahara.org is in the client repository, on the demo-mahara-org branch.
| |
| | |
| git fetch origin
| |
| git merge origin/1.0_STABLE
| |
| dch -v 1.0.X~testing-1 (changelog: 1.0.X)
| |
| make
| |
| | |
| Send it to the e-learning repo and install it.
| |
| | |
| </div></div>
| |
| | |
| ===Subpages===
| |
| | |
| * [[Developer_Area/Release_Instructions/Creating_a_GPG_key|Creating a GPG key]]
| |
| * [[Developer_Area/Release_Instructions/Release_script|Release script]]
| |