Actions

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

From Mahara Wiki

< Developer Area‎ | Release Instructions
(→‎Launchpad series: need to update both projects on Launchpad)
(20 intermediate revisions by 6 users not shown)
Line 1: Line 1:
Here are the things to do before running through the usual [[Developer Area/Release Instructions|release instructions]] when preparing a new major release.
+
Here are the things to do before and after running through the usual [[Developer Area/Release Instructions|release instructions]] when preparing a new major release.
 +
 
 +
= BEFORE the release =
 +
 
 +
== Release candidate ==
  
 
Major releases should be preceded by at least one [[Developer Area/Release Instructions/Release Candidate|release candidate]].
 
Major releases should be preceded by at least one [[Developer Area/Release Instructions/Release Candidate|release candidate]].
  
= Creating the new branch =
+
== Creating the new branch ==
 +
 
 +
The new branch '''should''' have been created as part of the first RC release. If it wasn't, then do it now. See the instructions under the Release Candidate page.
 +
 
 +
== Update the Readme file ==
 +
 
 +
Review the readme file and update it to reflect any changes, in particular around versions of PHP, Postgres, and MySQL / MariaDB supported and the minimum browser requirements. These need to be stated clearly.
 +
 
 +
For PHP versions, the minimum '''and''' maximum supported version needs to be listed to avoid confusion as PHP does release versions more frequently.
 +
 
 +
== Write the Change log & Release notes ==
  
* Create a new branch in the admin section of Gerrit
+
You'll need to write up the Change Log beforehand at least, because it gets included in the release's ZIP file. It should include any information about backwards-compatibility breaking.
* Copy the changelog from the previous stable branch
 
* Update the branch name in the "push" target of the Makefile
 
  
= Bump the version on master =
+
You can copy what you like from the [https://launchpad.net/mahara/1.9/1.9.0 1.9.0 change log and release notes].
  
* Go to the master branch and bump the version to 1.5.0dev (if you just created the 1.4_STABLE branch)
+
= AFTER the release =
  
= Bump the stable_version on mahara.org =
+
== Bump the stable_version on mahara.org ==
  
(This is what sets the right download link in the header.)
+
This is what sets the right download link in the header.
 +
And also sets the 'Latest version' info on the Mahara Administration dashboard for "Site information"
  
Here's what I added in <tt>htdocs/local/upgrade.php</tt> for the 1.4 release:
+
To do this you need to do 2 things:
  
if ($oldversion < 2011061501) {
+
1) Edit the <tt>htdocs/local/upgrade.php</tt> file and add a upgrade block, eg:
    set_config('mahara_stable_version', '1.4');
 
}
 
  
= Write the release notes =
+
  if ($oldversion < 2018102500) {
 +
    set_config('mahara_stable_version', '18.10');
 +
  }
  
You can copy what you like from the [http://mahara.org/interaction/forum/topic.php?id=3744 1.4 release notes].
+
2) Edit the <tt>htdocs/local/version.php</tt> file and change the version and release variables, eg:
 +
 
 +
  $config->version = 2018102500;
 +
  $config->release = '18.10.0';
 +
 
 +
Note: Deploying the change to testing site will not show change - only deploy to production will
  
 
== Generate the git stats ==
 
== Generate the git stats ==
  
Grab our version of <tt>gitdm</tt> from the [http://gitorious.org/mahara/mahara-scripts mahara-scripts repo]:
+
The git contributor stats go in the release announcement on the Mahara News forum. Grab our version of <tt>gitdm</tt> from the [https://gitlab.com/mahara/mahara-scripts mahara-scripts repo]:
  
  git clone git://gitorious.org/mahara/mahara-scripts.git
+
  git clone git@git.mahara.org:scripts/mahara-scripts.git
  
 
and here is how to generate the stats at the end:
 
and here is how to generate the stats at the end:
  
  GIT_DIR=~/code/mahara/.git git log -p -M --no-merges 1.3.0_RELEASE..1.4_STABLE | ./gitdm -c mahara.config -u -s -o results -h results.html
+
  cd ~/path/to/mahara.git
 +
git log -p -M --no-merges 1.3.0_RELEASE..1.4_STABLE > ~/mahara.log
 +
cd ~/code/mahara-scripts/gitdm/
 +
cat ~/mahara.log | ./gitdm -c mahara.config -u -s -z -o results -h results.html
  
Have a look at the <tt>results</tt> text file to ensure that developers are only listed once (otherwise add them to the <tt>mahara.aliases</tt> file). Also make sure that there is no "(unknown)" company by making sure that all of the necessary mappings are in <tt>mahara.domain-map</tt>.
+
Have a look at the <tt>results</tt> text file to ensure that developers are only listed once (otherwise add them to the <tt>mahara.aliases</tt> file). Also make sure that there is no "(unknown)" company by making sure that all of the necessary mappings are in <tt>mahara.domain-map</tt>. If there are "(unknown)" company results, look through the generated text file "database.dump" to locate the unmapped individuals/emails.
  
= Launchpad series =
+
== Launchpad series ==
  
 
When releasing 1.4, we did the following:
 
When releasing 1.4, we did the following:
Line 48: Line 69:
 
* Changed the status of [https://launchpad.net/mahara/1.2 1.2] to '''"Obsolete"''' and the description to '''"Old stable release of Mahara (no longer supported)"'''
 
* Changed the status of [https://launchpad.net/mahara/1.2 1.2] to '''"Obsolete"''' and the description to '''"Old stable release of Mahara (no longer supported)"'''
  
Make sure to update both the '''Mahara''' and '''Mahara-Lang''' projects.
+
Make sure to update both the [https://launchpad.net/mahara Mahara] and [https://launchpad.net/mahara-lang Mahara-Lang] projects.
 +
 
 +
== User manual ==
 +
 
 +
When releasing a major version, the user manual also needs some attention
 +
 
 +
* Change the boldness of the links in the sidebar to the latest release in all versions of the manual.
 +
* Change the sentence on the index page of the new release to include the release date.
 +
* Change the redirect in the maharadocs.postinst file in https://git.mahara.org/user-manual/manual-packaging to the latest version and ask a sysadmin at Catalyst to redo the package on the server.
 +
 
 +
== Announcements ==
 +
 
 +
There are a few places where the release should be announced:
 +
 
 +
* Release notes posted in the News forum (copy the format from the release notes for the previous release).
 +
* Identi.ca post which will also immediately post to Twitter.
 +
* Any other places where you want to announce the release.

Revision as of 00:44, 28 July 2019

Here are the things to do before and after running through the usual release instructions when preparing a new major release.

BEFORE the release

Release candidate

Major releases should be preceded by at least one release candidate.

Creating the new branch

The new branch should have been created as part of the first RC release. If it wasn't, then do it now. See the instructions under the Release Candidate page.

Update the Readme file

Review the readme file and update it to reflect any changes, in particular around versions of PHP, Postgres, and MySQL / MariaDB supported and the minimum browser requirements. These need to be stated clearly.

For PHP versions, the minimum and maximum supported version needs to be listed to avoid confusion as PHP does release versions more frequently.

Write the Change log & Release notes

You'll need to write up the Change Log beforehand at least, because it gets included in the release's ZIP file. It should include any information about backwards-compatibility breaking.

You can copy what you like from the 1.9.0 change log and release notes.

AFTER the release

Bump the stable_version on mahara.org

This is what sets the right download link in the header. And also sets the 'Latest version' info on the Mahara Administration dashboard for "Site information"

To do this you need to do 2 things:

1) Edit the htdocs/local/upgrade.php file and add a upgrade block, eg:

 if ($oldversion < 2018102500) {
    set_config('mahara_stable_version', '18.10');
 }

2) Edit the htdocs/local/version.php file and change the version and release variables, eg:

 $config->version = 2018102500;
 $config->release = '18.10.0';

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

Generate the git stats

The git contributor stats go in the release announcement on the Mahara News forum. Grab our version of gitdm from the mahara-scripts repo:

git clone [email protected]:scripts/mahara-scripts.git

and here is how to generate the stats at the end:

cd ~/path/to/mahara.git
git log -p -M --no-merges 1.3.0_RELEASE..1.4_STABLE > ~/mahara.log
cd ~/code/mahara-scripts/gitdm/
cat ~/mahara.log | ./gitdm -c mahara.config -u -s -z -o results -h results.html

Have a look at the results text file to ensure that developers are only listed once (otherwise add them to the mahara.aliases file). Also 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.

Launchpad series

When releasing 1.4, we did the following:

  • Changed the status of 1.5 to "Active development" and the description to "Future release of Mahara"
  • Changed the status of 1.4 to "Current stable release" and the description to "Stable release of Mahara"
  • Changed the status of 1.3 to "Supported" and the description to "Old stable release of Mahara"
  • Changed the status of 1.2 to "Obsolete" and the description to "Old stable release of Mahara (no longer supported)"

Make sure to update both the Mahara and Mahara-Lang projects.

User manual

When releasing a major version, the user manual also needs some attention

  • Change the boldness of the links in the sidebar to the latest release in all versions of the manual.
  • Change the sentence on the index page of the new release to include the release date.
  • Change the redirect in the maharadocs.postinst file in https://git.mahara.org/user-manual/manual-packaging to the latest version and ask a sysadmin at Catalyst to redo the package on the server.

Announcements

There are a few places where the release should be announced:

  • Release notes posted in the News forum (copy the format from the release notes for the previous release).
  • Identi.ca post which will also immediately post to Twitter.
  • Any other places where you want to announce the release.