Actions

Difference between revisions of "Developer Area/Release Instructions/Release day"

From Mahara Wiki

< Developer Area‎ | Release Instructions
 
(46 intermediate revisions by 3 users not shown)
Line 1: Line 1:
Not ready? [[Developer Area/Release Instructions/Pre-release investigation and tasks|> Go to 'Pre-release investigation and tasks]]'
+
Not ready? [[Developer Area/Release Instructions/Pre-release|> Go to 'Pre-release]]'
  
==📋 Final checks before starting release day==
+
'''These are instructions for the day of a Major release.'''
 +
{{Final_Checks}}
  
🟡 '''Security team''' (if you don't have +2 review status, you won't be able to see these patches)
+
{{Changelog_And_Release_Notes}}
  
🚨 Make sure that any security reviews/patches are merged before proceeding 🚨
+
See paste: [https://paste.wgtn.cat-it.co.nz/BjqzmddeQ8RLPOhq#HJYM6/6JF46ErvKAHVR0Lw$0 release notes template for major releases].
  
*Merge the 'Private' security patches.
+
[[File:Major release release notes 21.10.png|774x774px|link=]]
*Update the related Launchpad bugs to 'Public security'.
 
  
🟡 '''Release manager'''
+
{{Release_Script}}
  
*CVE #'s - Security issues have an assigned CVE number?
+
{{Testing}}
*Backporting - security fixes backported to all supported versions that need them?
 
*Bugs fixed - all bugs going into his release have their fixes ''merged'' for all supported versions?
 
*Comms - to Mahara partners + drafted the [[Developer Area/Release Instructions/Pre-release investigation and tasks#.F0.9F.93.B0 Comms|forum posts]]?
 
  
🟡 '''All devs'''
+
{{Upload_Tarballs}}
  
*What minor point release are you going to do?
+
{{Update bugs statuses}}
*(Security team) Cherry-pick the security bugs with the status ' Confirmed' to your minor point branch. e.g. _DEV
 
*Have you created a [[Developer Area/Release Instructions/Pre-release investigation and tasks#Creating a release on Launchpad|release]] on the milestone on Launchpad to receive the release generated tarballs?
 
*<code>git pull [https://git.mahara.org/scripts/mahara-scripts mahara-scripts]</code>
 
*Valid GPG - do you have a [https://wiki.mahara.org/wiki/Developer_Area/Release_Instructions/Creating_a_GPG_key valid GPG key] added to your Launchpad account? See https://launchpad.net/~username/+editpgpkeys
 
*<code>lptools</code> - do you have the lp-upload-project installed for uploading the release tars? <code> apt-get install lptools</code>
 
  
==📓 Prepare the changelog and release notes==
+
{{Update your milestone}}
Use the templates below to structure your changelog and release notes.
 
  
====(Release candidate) Skip the changelog and release notes====
+
{{Update wiki.mahara.org releases page}}
Do not populate the change log. In the release notes put something similar to ''<nowiki/>'First release candidate for 1.4''<nowiki/>'.
 
  
====Changelog template:====
+
{{Update the language packs}}
Note: You can copy the list of bugs from the milestone page and re-format the list. Remove the 'bump version number' commits text. Tip: You can use replace with regex '         .*'  with <nowiki>''</nowiki>.
 
Bug XXXXXXX: <Title of bug>
 
  
Bug XXXXXXX: <Title of bug>
+
{{Update MITRE about release for CVE number publication}}
  
Bug XXXXXXX: <Title of bug>
+
{{Announcements}}
  
...<br />
 
====Release notes template:====
 
Note: Replace the <code><XX.XX.X></code> with the milestone/version you are working on.
 
Mahara <code><XX.XX.X></code> Release Notes
 
 
This is a stable release of Mahara <code><XX.XX></code>. Stable release are fit for general use.
 
 
If you find a bug, please report it to the tracker:
 
 
https://bugs.launchpad.net/mahara/+filebug
 
 
This release includes an upgrade path from 1.1.0.
 
 
If you wish to upgrade, we encourage you to make a copy of your website and test
 
 
the upgrade on it first, to minimise the effect of any potential unforeseen problems.
 
                                                           
 
==⚡ The release script==
 
 
===About the script===
 
 
*A git repo will be created at <code>/tmp/mahara.####/mahara/</code> cloned from https://git.mahara.org/mahara/mahara .
 
*Pre-built Mahara archives (<code>.zip</code>, <code>.tar.gz.asc</code>, and <code>.tar.bz2.asc</code>) are generated and put into your current folder.
 
*You will get a <code>release-X.Y.Z-cleanup.sh</code> script to run later.
 
*( <code>.0</code> releases) A new <code>_STABLE</code> branch is created off the <code>_DEV</code> branch.
 
**Look in the local <code>/tmp/</code> clone of mahara to check that it does.
 
**Check that the the release cleanup script pushes things to the right branch
 
 
===Run the script===
 
 
#Go into <code>mahara-scripts</code>
 
#Run <code>./release.php X.Y.Z  X.Y_DEV</code> , i.e. <code>./release.php [target milestone] [dev branch]</code> (This is creating a zip file called X.Y.Z from the X.Y_DEV branch)
 
#When prompted, insert your changelog.
 
 
Any data you enter for the changelog or release notes prompts will go into the Launchpad release page. You can enter it here, or leave it empty here and enter it directly into the Launchpad webpage.
 
 
'''Check the terminal output in case there are GPG errors'''
 
 
E.g. <code>Tag new version bump commit as 'X.YRC2_RELEASE' error: gpg failed to sign the data error: unable to sign the tag</code>
 
 
So this is what I did to fix it, all commands are on command line:
 
 
#Update the gpg program with: <code> git config --global gpg.program gpg2 </code>
 
#Test if it is working with: <code> echo "test" | gpg2 --clearsign</code>
 
 
It wasn't so I had to do: <code> export GPG_TTY=$(tty)</code>
 
 
then run again <code> echo "test" | gpg2 --clearsign</code>
 
 
Run <code>release.php</code> command again and check if it still gives the error.
 
 
'''Do not reboot your machine''' in the middle of doing a release or you will have to run through the release script again.
 
 
Note: For release candidates the commit message should be empty.
 
 
==✅ Testing==
 
With continuous Behat testing throughout development, we only need to some basic manual testing. 
 
 
===Extract the build and prep the database===
 
Test that we can install Mahara with the pre-built packages.
 
 
#Extract the build (<code>.tar</code> or <code>.zip</code>) of your pre-built Mahara and make sure you can connect to it via web installer.
 
#Drop the database and create a new blank one.
 
 
===Test case: Install the site with the web interface===
 
 
#Go to your Mahara site and click 'Install'.
 
#Reset your database and repeat with MySQL/PostgreSQL.
 
 
'''Note:''' If we are doing a <code>.0</code> release the install will complain about missing <code>$versions->$currentmajorversion</code>->latest release number but don't panic this is because the local copy of the release has the series version that doesn't exist upstream yet so we can ignore this warning·
 
 
===Test case: Manual upgrade with the CLI and the web interface===
 
Web interface
 
 
#Install a fresh site on version <code>X.Y.Z(-1)</code>, i.e. (an earlier version).
 
#Create a portfolio, a blog with a blogpost, a group with a forum and forum post.
 
#Switch the code to your current release.
 
#Check that everything still works.
 
#Go to the site and click 'Upgrade' to get the site version to <code>X.Y.Z</code> .
 
#Repeat with PostgreSQL/MySQL.
 
 
CLI
 
 
#Install a fresh site on version <code>X.Y.Z(-1)</code>, i.e. (an earlier version).
 
#Create a portfolio, a blog with a blogpost, a group with a forum and forum post.
 
#Switch the code to your current release.
 
#Upgrade to <code>X.Y.Z</code> with the CLI script <code>htdocs/admin/cli/upgrade.php</code>
 
#Check that everything still works.
 
#Repeat with PostgreSQL/MySQL.
 
 
==🚀 Sign and upload the tarballs==
 
Run upload the release and clean up any temporary files with <code>./release-X.Y.Z-cleanup.sh</code>
 
 
'''Note I''': If running this file stops before completion for any reason you will need to edit it and comment out the bits that did finish so that you don't run those buts twice then try the script again. For example the script does the bit where it pushes the tag to the git remote and signs the zipped files but doesn't upload them - you would need to comment out the 'git push' lines and the 'gpg --armor' lines.
 
 
'''Note II''': If the zipped files fail to upload to Launchpad via the script then you will need to manually upload the zipped files and their corresponding .asc files. To do this go to the milestone page in Launchpad and click the 'Add download file' link. Set the description to: release tarball and choose the matching zipped and .asc file to upload. You will need to do this for all the three types: <code>.zip, .tar.bz2, .tar.gz</code>
 
 
==🐛 Update bugs on the tracker==
 
Go to Launchpad and click on all of the bugs targeted for that milestone and move them from 'Fix committed' to 'Fix released'.
 
 
'''OR'''
 
 
In Firefox, go to the milestone page and open all the bugs in new tabs at once by pasting the following into the browser console.
 
var result = document.evaluate("//tbody//tr[contains(., 'Committed')]//a[contains(@href, 'bugs')]", document, null, XPathResult.ANY_TYPE,null ); var mycount=0; while(node = result.iterateNext()) { window.open(node.href, '_blank'); mycount++; if (mycount == 50) { break; } }
 
You will ned to allow popups for the site for this to work and it will open up to 50 bugs where the status is 'Committed'. If you have more than 50 to do - mark the first ones 'released' - refresh the list and do again.
 
 
Now is also a good time to create the next release number in the series. Any remaining bugs that were not fixed for this release may be transferred to the next one, if they're still on the roadmap but were simply delayed.
 
 
==📔 Put the release notes on the wiki page==
 
This is just adding a link to the right page on Launchpad, we no longer have a duplicate copy of the release notes on the wiki.
 
 
[[Releases|Release notes page]]
 
 
==📗 Update wiki.mahara.org releases page==
 
 
#Go to the [[Releases|releases page]].
 
#Edit 'Current and upcoming releases.
 
#Update the text: ''"The latest '''stable''' version of Mahara is <code>MAJOR_VERSION</code> , released on <code>DATE</code>"''
 
#Add a new entry to the table for the new release.
 
#Update the major version where 18 months has passed since its release to be 'unsupported'.
 
 
==🌏 Update the language packs==
 
🟡 Release manager
 
 
[[Developer Area/Language Packs/Launchpad Branching|Create a new translation branch on launchpad.net and update the language scripts]] for the new release so that they appear on http://langpacks.mahara.org.
 
 
Note: The number of language packs we support can be more than the supported Mahara versions as some people want to update old lang packs.
 
 
==📣 Announcements==
 
🟡  Release manager | Kristina
 
 
===General announcements===
 
 
#Publish your prepared [https://mahara.org/interaction/forum/view.php?id=43 security forum] and [https://mahara.org/interaction/forum/view.php?id=1 news forum] posts.
 
#(RC only) Publish news [[Developer Area/Release Instructions/Release day#.28Release candidate.29 Announcements|forum posts to get people to test the release]].
 
#(Major release only) Publish news [[Developer Area/Release Instructions/Release day#.28Major release.29 Announcements|forum posts to announce the major release.]]
 
 
==🔒 Update MITRE about release for CVE number publication==
 
 
🟡  Kristina
 
🟡  Kristina
  
If the release included security updates for which CVE numbers had been issued, [https://cveform.mitre.org/ request an update to the CVE number] so it can be published.
 
 
==📋 Additional tasks==
 
Go to [[Developer Area/Release Instructions/Release day#.28Major%20release.29%20Announcements|'Major release' tasks]]
 
 
===(Release candidate) Announcements===
 
The main purpose of an RC is to get people to test the release for any major bugs. Therefore, we do not consider the RC as a release and only announce it through: [https://twitter.com/maharaproject Twitter], IRC, and the mahara.org news forum.
 
 
===(Release candidate) Update master.dev.mahara.org===
 
Updating master.dev.mahara.org however is useful for users who do not have somewhere to set up a test instance but would like to check out the changes.
 
 
===(Release candidate) News forum post template for RC1===
 
🟡  Kristina
 
 
[https://mahara.org/interaction/forum/topic.php?id=8934 Example for 21.10] and [https://mahara.org/interaction/forum/topic.php?id=8934 22.04].
 
 
===(Release candidate) News forum template for second and/or final RC===
 
''Note: Outdated - needs updating''
 
 
Subject: Second release candidate for Mahara 1.4 available
 
 
Based on the feedback we have received so far, this will most likely be the last release candidate before the final 1.4 release:
 
 
*https://launchpad.net/mahara/1.4/1.4rc2
 
 
New Features for the Release Candidate are listed on Launchpad with the newfeature tag:
 
 
*https://bugs.launchpad.net/mahara/+bugs?field.milestone%3Alist=64606&field.tag=nominatedfeature
 
 
We've also done lots of bug fixing is this release cycle. The full list of changes that have been made for 1.4 can be found by clicking here.
 
 
*https://bugs.launchpad.net/mahara/+bugs?field.status%3Alist=FIXCOMMITTED&field.status%3Alist=FIXRELEASED&field.milestone%3Alist=64606
 
 
If you haven't had a chance to test it out yet, please do so now and report any bugs on the tracker:
 
 
*https://bugs.launchpad.net/mahara/+filebug
 
 
This is your last chance to make sure your upgrade to 1.4 will be smooth. If nothing major is reported in the next few days, we will be cutting the 1.4.0 release in about a week.
 
 
Cheers,
 
 
The 1.4 Release Managers
 
 
===(Major release) Announcements===
 
 
Release notes posted in the [https://mahara.org/interaction/forum/topic.php?id=8955 News forum] (copy the format from the release notes for the previous release).
 
Release notes posted in the [https://mahara.org/interaction/forum/topic.php?id=8955 News forum] (copy the format from the release notes for the previous release).
  
Line 237: Line 43:
 
*Any other places where you want to announce the release.
 
*Any other places where you want to announce the release.
  
===(Major release) Manage merge conflicts in htdocs/lib/version.php===
+
{{Additional tasks}}
When backporting patches, sometimes the <code>htdocs/lib/version.php</code> will get merge conflicts because of a new DB upgrade step.
 
 
 
E.g. for 21.10.2
 
<<<<<<< HEAD  (abcdef Bug 012345: ...)
 
 
 
$config->version = 202108021;
 
 
 
$config->series = '21.10';
 
 
 
$config->release = '21.10.2testing';
 
 
 
$config->minupgradefrom = 2017031605;
 
 
 
$config->minupgraderelease = '18.10.0 (release tag 18.10.0_RELEASE)';
 
 
 
=======
 
 
 
$config->version = 2022041400;
 
 
 
$config->series = '22.10';
 
 
 
$config->release = '22.10dev';
 
 
 
$config->minupgradefrom = 2020013006;
 
 
 
$config->minupgraderelease = '20.04.0 (release tag 20.04.0_RELEASE)';
 
 
 
>>>>>>> CHANGE (Bug 123456: ...)
 
Solve the conflict:
 
 
 
#Keep the set of code that matches to the version you're working with, e.g. in this case, the top section.
 
#Increment the <code>$config->version</code> number by 1.
 
#Copy the incremented version number and replace the last step in <code>htdocs/lib/db/upgrade.php</code>
 
#Check that the new number is higher than the previous upgrade step.
 
 
 
In certain situations, $config->version number needs to be incremented and copied over the most latest DB upgrade steps, ensuring that it's later than the other DB upgrade steps.
 
  
===(Major release) Bump the <code>stable_version</code> on mahara.org===
+
===Bump the <code>stable_version</code> on mahara.org===
 
This is done via the <code>htdocs/admin/cli/create_version.php</code> script which is controlled by cron and will update once a day.
 
This is done via the <code>htdocs/admin/cli/create_version.php</code> script which is controlled by cron and will update once a day.
  
Line 282: Line 52:
 
Note: Deploying the change to testing site will not show change - only deploy to production will
 
Note: Deploying the change to testing site will not show change - only deploy to production will
  
===(Major release) Update community sites install (currently Catalyst hosted)===
+
===Update community sites install (currently Catalyst hosted)===
 +
Check if any of the merge-branches need attention: https://go.elearning.catalyst.net.nz/go/pipelines#!/
  
*demo.mahara.org, including prep site and change the version number and release date on the homepage and dashboard page (via Admin menu -> Configure site -> Static pages)
+
*[[demo.mahara.org]], including prep site and change the version number and release date on the homepage and dashboard page (via Admin menu -> Configure site -> Static pages)
*mahara.org (at minimum to latest minor point release of the supported version it runs on)
+
*[[mahara.org]] (at minimum to latest minor point release of the supported version it runs on)
*master.dev.mahara.org
+
*[[master.dev.mahara.org]]
  
 
Update the installed language packs on the demo site. As a guideline, language packs that are 90% or more translated should be installed.
 
Update the installed language packs on the demo site. As a guideline, language packs that are 90% or more translated should be installed.
  
===(Major release) Generate the git stats===
+
===Generate the git stats===
 
The git contributor stats go in the release announcement on the Mahara News forum.
 
The git contributor stats go in the release announcement on the Mahara News forum.
  
Line 310: Line 81:
 
*If there are "(unknown)" company results, look through the generated text file "<code>database.dump</code>" to locate the unmapped individuals/emails.
 
*If there are "(unknown)" company results, look through the generated text file "<code>database.dump</code>" to locate the unmapped individuals/emails.
  
===(Major release) Update Launchpad series statuses===
+
===Update Launchpad series statuses===
 
Update the status of our series in Launchpad for both the [https://launchpad.net/mahara Mahara] and [https://launchpad.net/mahara-lang Mahara-Lang] projects:
 
Update the status of our series in Launchpad for both the [https://launchpad.net/mahara Mahara] and [https://launchpad.net/mahara-lang Mahara-Lang] projects:
  
*Change the status of the <u>future/trunk series</u> to '''"Active development"''' and its description to '''"Release of Mahara X.Y, scheduled for April/October YYYY"'''
+
*Change <u>Future/trunk series</u> to '''"Active development"''' and its description to '''"Release of Mahara X.Y, scheduled for April/October YYYY"'''
*Change the status of the series <u>just released</u> to '''"Current stable release"'''
+
*Change the series <u>just released</u> to '''"Current stable release"'''
*Change the status of the series of all the <u>supported series</u> to '''"Supported"'''
+
*Change the series of all the <u>supported series</u> to '''"Supported"'''
*Change the status of the series that has just fallen <u>out of support</u> to '''"Obsolete"'''
+
*Change the series that has just fallen <u>out of support</u> to '''"Obsolete"'''
  
===(Major release) Update the Mahara manual===
+
===Update the Mahara manual===
  
 
#Remove the version that is now out of support from the quick links to older manuals.
 
#Remove the version that is now out of support from the quick links to older manuals.

Latest revision as of 00:08, 7 May 2022

Not ready? > Go to 'Pre-release'

These are instructions for the day of a Major release.

📋 Final Checks

🟡 Security team (if you don't have +2 review status, you won't be able to see these patches)

🚨 Make sure that any security reviews/patches are merged before proceeding 🚨

  • Merge the 'Private' security patches.
  • Update the related Launchpad bugs to 'Public security'.

🟡 Release manager

  • CVE #'s - Security issues have an assigned CVE number?
  • Backporting - security fixes backported to all supported versions that need them?
  • Bugs fixed - all bugs going into his release have their fixes merged for all supported versions?
  • Comms - to Mahara partners + drafted the forum posts?

🟡 All devs

  • Confirm your minor point release number, i.e. check the latest minor point release and add 1, e.g. 21.10.4 -> 21.10.5
  • (Security team) Cherry-pick the security bugs with the status ' Confirmed' to your minor point branch. e.g. _DEV
  • Create a release on the milestone on Launchpad to receive the release generated tarballs
  • git pull mahara-scripts
  • Valid GPG - ensure you have a valid GPG key added to your Launchpad account: See https://launchpad.net/~username/+editpgpkeys
  • lptools - ensure you have the lp-upload-project installed for uploading the release tars: apt-get install lptools

📓 Changelog and release notes

Use the templates below to structure your changelog and release notes. These are just to be preped. Filenames don't matter, the text is used later.

Changelog template

Note: You can copy the list of bugs from the milestone page (https://launchpad.net/mahara/+milestone/XX.YY.Z) and re-format the list.

Changelog template.png

Release notes templates

See paste: release notes template for major releases.

Major release release notes 21.10.png

⚡ The release script

  • A git repo will be created at /tmp/mahara.####/mahara/ cloned from https://git.mahara.org/mahara/mahara .
  • It builds Mahara archives based on the given _DEV branch and puts thme into your current folder. ( .zip, .tar.gz.asc, and .tar.bz2.asc)
  • You will get a release-X.Y.Z-cleanup.sh script to run later.


Run the script

  1. Go into mahara-scripts and git pull the latest version.
  2. Run ./release.php X.Y.Z X.Y_DEV.
    • X.Y.Z is the new branch that will be made. This is also used in the archive file names.
    • X.Y_DEV is the existing branch we will create the new release from.
    • If the Z in X.Y.Z is "0" this will also create a new _STABLE branch.
  3. When prompted, insert your changelog.

Any data you enter for the prompts will go into the Launchpad release page. You can enter it here, or leave it empty here and enter it directly into the Launchpad webpage.

Check the terminal output in case there are GPG errors

E.g. Tag new version bump commit as 'X.YRC2_RELEASE' error: gpg failed to sign the data error: unable to sign the tag

So this is what I did to fix it, all commands are on command line:

  1. Update the gpg program with: git config --global gpg.program gpg2
  2. Test if it is working with: echo "test" | gpg2 --clearsign

It wasn't so I had to do: export GPG_TTY=$(tty)

then run again echo "test" | gpg2 --clearsign

Run release.php command again and check if it still gives the error.

Do not reboot your machine in the middle of doing a release or you will have to run through the release script again.

Note: For release candidates the commit message should be empty.

✅ Testing

With continuous Behat testing throughout development, we only need to some basic manual testing.

Extract the build and prep the database

Test that we can install Mahara with the pre-built packages.

  1. Extract the build (.tar or .zip) of your pre-built Mahara and make sure you can connect to it via web installer.
  2. Drop the database and create a new blank one.

Test case #1: Install the site with the web interface

  1. Go to your Mahara site and click 'Install'.
  2. Reset your database and repeat with MySQL/PostgreSQL.

Note: If we are doing a .0 release the install will complain about missing $versions->$currentmajorversion->latest release number but don't panic this is because the local copy of the release has the series version that doesn't exist upstream yet so we can ignore this warning·

Test case #2: Manual upgrade with the CLI and the web interface

Web interface

  1. Install a fresh site on version X.Y.Z(-1), i.e. (an earlier version).
  2. Create a portfolio, a blog with a blogpost, a group with a forum and forum post.
  3. Switch the code to your current release.
  4. Check that everything still works.
  5. Go to the site and click 'Upgrade' to get the site version to X.Y.Z .
  6. Repeat with PostgreSQL/MySQL.

CLI

  1. Install a fresh site on version X.Y.Z(-1), i.e. (an earlier version).
  2. Create a portfolio, a blog with a blogpost, a group with a forum and forum post.
  3. Switch the code to your current release.
  4. Upgrade to X.Y.Z with the CLI script htdocs/admin/cli/upgrade.php
  5. Check that everything still works.
  6. Repeat with PostgreSQL/MySQL.

🚀 Sign and upload the tarballs

Run ./release-X.Y.Z-cleanup.sh to upload the release and clean up any temporary files.

Note I: If running this file stops before completion for any reason you will need to edit it and comment out the bits that did finish so that you don't run those buts twice then try the script again. For example the script does the bit where it pushes the tag to the git remote and signs the zipped files but doesn't upload them - you would need to comment out the 'git push' lines and the 'gpg --armor' lines.

Note II: If the zipped files fail to upload to Launchpad via the script then you will need to manually upload the zipped files and their corresponding .asc files. To do this go to the milestone page in Launchpad and click the 'Add download file' link. Set the description to: release tarball and choose the matching zipped and .asc file to upload. You will need to do this for all the three types: .zip, .tar.bz2, .tar.gz

🐛 Update bugs statuses

Go to Launchpad and click on all of the bugs targeted for that milestone and move them from 'Fix committed' to 'Fix released'.

OR

In Firefox, go to the milestone page and open all the bugs in new tabs at once by pasting the following into the browser console.

var result = document.evaluate("//tbody//tr[contains(., 'Committed')]//a[contains(@href, 'bugs')]", document, null, XPathResult.ANY_TYPE,null ); var mycount=0; while(node = result.iterateNext()) { window.open(node.href, '_blank'); mycount++; if (mycount == 50) { break; } }

You will ned to allow popups for the site for this to work and it will open up to 50 bugs where the status is 'Committed'. If you have more than 50 to do - mark the first ones 'released' - refresh the list and do again.

Now is also a good time to create the next release number in the series. Any remaining bugs that were not fixed for this release may be transferred to the next one, if they're still on the roadmap but were simply delayed.

📔 Update your milestone

  1. Paste your release notes into the 'Release notes' area.
  2. Check that the milestone is inactive now that it has a release.

Screenshot showing the status for a milestone for it is 'inactive'.

📗 Update wiki.mahara.org releases page

  1. Go to the releases page's section 'Current and upcoming releases.'
  2. Update the text: "The latest stable version of Mahara is MAJOR_VERSION , released on DATE"
  3. Add a new row for the major release. (If you edit the area, there is a template available to copy)
  4. Add the release date and release notes for the minor point releases.
  5. Update the major version where 18 months has passed since its release to be 'unsupported'.

Updating current and upcoming releases.png

🌏 Update/test the language packs

Create a new translation branch on launchpad.net and update the language scripts for the new release so that they appear on http://langpacks.mahara.org.

Check that the language packs have updated:

  1. Install a site on the released version.
  2. Install the Japanese language pack (a fully translated lang pack is easier to check with)

Note: The number of language packs we support can be more than the supported Mahara versions as some people want to update old lang packs.

🔒 Update MITRE about release for CVE number publication

🟡 Kristina

If the release included security updates for which CVE numbers had been issued, request an update to the CVE number so it can be published.

📣 Announcements

🟡 Kristina

Release notes posted in the News forum (copy the format from the release notes for the previous release).

  1. Publish the news forum post to announce the major release (includes git stats).
  2. Change the topic of #mahara and include a link to forum topic on #mahara-dev
  3. Make a post in the following socials:

📋 Additional tasks

Manage merge conflicts in version.php in backports

When backporting patches, sometimes the htdocs/lib/version.php will get merge conflicts because of a new DB upgrade step.

Example backporting from 22.04 to 21.10.png

Solve the conflict:

  1. Keep the set of code that matches to the version you're working with, e.g. in this case, the top section.
  2. Increment the $config->version number by 1.
  3. Copy the incremented version number and replace the last step in htdocs/lib/db/upgrade.php
  4. Check that the new number is higher than the previous upgrade step.

In certain situations, $config->version number needs to be incremented and copied over the most latest DB upgrade steps, ensuring that it's later than the other DB upgrade steps.

Bump the stable_version on mahara.org

This is done via the htdocs/admin/cli/create_version.php script which is controlled by cron and will update once a day.

If you can't wait for the cron you can log into the server and run the CLI script manually:

sudo -u www-data php create_version.php

Note: Deploying the change to testing site will not show change - only deploy to production will

Update community sites install (currently Catalyst hosted)

Check if any of the merge-branches need attention: https://go.elearning.catalyst.net.nz/go/pipelines#!/

  • demo.mahara.org, including prep site and change the version number and release date on the homepage and dashboard page (via Admin menu -> Configure site -> Static pages)
  • mahara.org (at minimum to latest minor point release of the supported version it runs on)
  • master.dev.mahara.org

Update the installed language packs on the demo site. As a guideline, language packs that are 90% or more translated should be installed.

Generate the git stats

The git contributor stats go in the release announcement on the Mahara News forum.

  1. Clone our version of gitdm from the mahara-scripts repo: git clone [email protected]:scripts/mahara-scripts.git
  2. Get the name of the current release branch, e.g. 21.10_DEV
  3. Get the previous branch's first release tag, e.g. 21.04.0_RELEASE

Generate the stats:

  1. cd ~/path/to/mahara.git (your local mahara repo)
  2. git log -p -M --no-merges 21.04.0_RELEASE..21.10_DEV > ~/mahara.log
  3. cd ~/code/mahara-scripts/gitdm/
  4. cat ~/mahara.log | ./gitdm -c mahara.config -u -s -z -o results -h results.html

Check the results file:

  • Ensure that developers are only listed once (otherwise add them to the mahara.aliases file).
  • Make sure that there is no "(unknown)" company by making sure that all of the necessary mappings are in mahara.domain-map.
  • If there are "(unknown)" company results, look through the generated text file "database.dump" to locate the unmapped individuals/emails.

Update Launchpad series statuses

Update the status of our series in Launchpad for both the Mahara and Mahara-Lang projects:

  • Change Future/trunk series to "Active development" and its description to "Release of Mahara X.Y, scheduled for April/October YYYY"
  • Change the series just released to "Current stable release"
  • Change the series of all the supported series to "Supported"
  • Change the series that has just fallen out of support to "Obsolete"

Update the Mahara manual

  1. Remove the version that is now out of support from the quick links to older manuals.
  2. Mention on the now unsupported manual that it is unsupported.
  3. Change the sentence on the index page of the new release to include the release date and add a link to the release announcement.
  4. Change the redirect in the index.html of the manual-builder package (Catalyst only).