Release process: Difference between revisions

Revision as of 06:22, 25 November 2013

Roles

Role	Person responsible
Lead Developer	Martin Dougiamas
Integration Lead	Eloy Lafuente
Community Manager	Helen Foster
AMOS Maintainer	David Mudrák
Moodle Docs Maintainer	David Mudrák
Plugins Directory Maintainer	Aparup Banerjee
Testing Maintainer	David Monllaó
QA Master Site Maintainer	Helen Foster
Digital Marketing Specialist	X.Y. Ng
System Administrator	Matthew Spurrier
Development Manager	Michael de Raadt

Roles updated 18 June 2013.

<html>

6 weeks prior

#	Major	Task	Responsibility
1.	✓	Create the next "X.Y+1" (next dev) version in the Tracker (MDL and CONTRIB), so people can move delayed stuff to next major release if needed.	Integration Lead
2.	✓	Create a "Must fix for X.Y" version in the tracker.	Integration Lead
3.	✓	Freeze stable development and post in the General developer forum to inform everyone of the freeze. (example)	Development Manager
4.	✓	Check qa_test_required-labelled issues and create new QA tests as required.	Community Manager
5.	✓	Remove tests that have been converted to Behat tests from the QA master list. Review tests that cannot be tested on qa.moodle.net by mere mortals and label these with test_server_required.	Testing Maintainer

4 weeks prior

#	Major	Task	Responsibility
1.	✓	Start working on the release notes (template) of the upcoming version.	Development Manager
2.	✓	Release normal weeklies but with these changes in the master branch: version.php: Move to $maturity = MATURITY_BETA and $release = 'X.Ybeta (Build:xxxxxxxx)' tag git repo with: "vX.Y.0-beta" (and MOODLE_XY_BETA as description and CVS tag) And make packages available under download.moodle.org (and windows). Promote master up in the download page and adjust info for it.	Integration Lead
3.	✓	(Optionally) Announce Beta release in forums (ideally once packages are available).	Integration Lead
4.	✓	Review documentation for all issues with labels "dev_docs_required", removing this label when relevant docs are updated.
5.	✓	During the QA weeks integration becomes continuous; release STABLE weeklies normally but master release as often as possible (or on demand).	Integration Lead
6.	✓	At some points produce release candidates (Z = 1, 2, 3..), which are normal builds with: version.php: Move to $maturity = MATURITY_RC and $release = 'X.YrcZ (Build:xxxxxxxx)' tag git repo with: "vX.Y.0-rcZ" (and MOODLE_XY_RCZ as description and CVS tag) Make packages available under download.moodle.org (and Windows).	Integration Lead
7.	✓	Add a new version in the Plugins Directory with the beta version build number and the anticipated release version build number (https://moodle.org/plugins/admin/softwareversions.php).	Plugins Directory Maintainer
8.	✓	Tidy up current latest en version of Moodle Docs prior to copying it to create new version wiki as described in New docs version process.	Moodle Docs Maintainer
9.	✓	Prepare a fresh installation of the QA Master site based on the beta code to make sure the site is not affected by incremental upgrade steps during the development cycle.	QA Master Site Maintainer
10.	✓	Create new QA test cycle and invite community volunteers to start QA testing.	Community Manager
11.	✓	Update the QA testing dashboard.	Development Manager
12.	✓	Monitor QA fails. Check each fail is real and if so ensure an MDL issue has been created and correctly linked and labelled.	Testing Maintainer
13.	✓	Monitor MDL issues created for QA fails. Add them to the "Must fix for X.Y" list and get a developer to work on the issue immediately.	Development Manager

3 weeks prior

#	Major	Minor	Task	Responsibility
1.	✓		Prompt developers to begin QA tests marked test_server_required.	Development Manager
2.	✓		Create new en and de Moodle Docs version wikis.	Moodle Docs Maintainer
3.	✓	✓	Check docs_required-labelled issues and write new documentation, removing the label and commenting in the issue when the work is done.	Moodle Docs Maintainer
4.	✓		Go through all points listed under 3 weeks prior in New docs version process.	Moodle Docs Maintainer

2 weeks prior

#	Major	Minor	Task	Responsibility
1.	✓		Prompt developers to complete remaining QA tests. Ensure all QA tests are completed and passed by the end of the week.	Development Manager

1 week prior

#	Major	Minor	Task	Responsibility
1.	✓		Clone as many filters as needed in the Tracker, modifying them to point to the new, upcoming, branch (keeping same perms, title...).	Integration Lead
2.	✓	✓	Create new minor version X.Y.Z+1 in the Tracker (MDL and CONTRIB). Archive any version > 6 months old.	Integration Lead
3.	✓		Clone MDL-42701 and bump all versions, requires and dependencies along all plugins in codebase to current date.	Integration Lead
4.	✓	✓	Post a "Heads-up" message on the Partners forum and General Developer forum.	Development Manager
5.	✓	✓	Post a "Heads-up" message on Twitter and other outlets.	Digital Marketing Specialist
6.	✓	✓	Merge fixes from en_fix pack and then integrate them.	AMOS Maintainer
7.	✓		In https://github.com/moodlehq/moodle-behat-extension project: For the new stable version: Create a MOODLE_XY_STABLE branch from master Hardcode upstream projects versions in moodle-behat-extension/composer.json according to the latest pulled versions when installing/updating the dependencies to avoid upstream changes breaking stable branches tests Add a 1.XY.n tag to point to this new branch last commit For master: Add a 1.X(Y+1).0 tag for the new release in the master branch Clone MDL-39489, implement, and send it to integration (integration_held label).	Testing Maintainer
8.	✓	✓	Identify security issues that need to be integrated using the security_held label. Integrate from provided patches into supported branches (including branches supported only for security issues). Ensure security issues are given priority in weekly integration and testing.	Integration Lead
9.	✓	✓	Collect security issues into a clone of MDL-39530 to prepare for release of Security Advisories. Determine which security issues will be integrated. Request CVE Identifiers by emailing issue descriptions to distros@vs.openwall.org with a message like... `The following security issues have been discovered in Moodle. We request CVE Identifiers for these issues. We will be releasing the security announcements for these on moodle.org on XXX at 12noon AWST which is 04:00 UTC.` The email subject should include the characters `[vs]`. The format needs to be plain text or encrypted. When granted CVE Identifiers, our issues should appear in the CVE list. More instructions are available. Post security issues as a reply to the "Heads-up" message on the Partners forum.	Development Manager
10.	✓	✓	Review and complete the release notes for the upcoming minor versions. Ensure all issues labelled with "ui_change" or "api_change" are listed as functional or API changes respectively in the release notes.	Development Manager
11.	✓		Check on the "Must fix for X.Y version". Filter out unrealistic issues.	Development Manager
12.	✓		Upgrade moodle.org (test server first, then production)	System Administrator

Releasing

Packaging

This should happen immediately before the next integration cycle begins on Monday (i.e., some days after last weekly, 2 days prior to official release).

#	Major	Minor	Task	Responsibility
1.	✓	✓	Make sure there are no real blockers introduced in the last weekly (install / upgrade ...)	Integration Lead
2.	✓	✓	Verify all unit tests and integration tests have passed.	Integration Lead
3.	✓		Verify QA tests have passed.	Integration Lead
4.	✓	✓	For major releases only: Update the CI server(s) by cloning all the "master" jobs to a new "MXY" view. Adjust "master" compare DB jobs to check for upgrade from MOODLE_XY_STABLE. Follow the "mdlrelease" steps: Run the prerelease.sh script to generate the target minor (--type minor) and major (--type major) releases and their corresponding tags. Follow the on-screen instructions. Triple verify all changes are correct! Push changes to integration.git Once CI servers have ended and all jobs have passed, run the release.sh script to apply the changes to moodle.git	Integration Lead
5.	✓	✓	Post a "git repos updated & tagged" message on the Partner forum	Integration Lead
6.	✓		Create a new MOODLE_XY+1_STABLE branch in https://github.com/moodlehq/moodle-performance-comparison and set the new release commit hash as $basecommit	Testing Maintainer
7.	✓	✓	Wait for the automated moodle-package to finish building for all versions. Verify the process has ended successfuly (email). For major releases only: Use the prerelease.sh script (--type back-to-dev) to move master to next X.Y+1 development version/branch. And push changes to integration.git - note this will lead to the "versions checker" failing for master, no problem, it will be fixed by the 1st cloned issue at #11 below).	Integration Lead
8.	✓	✓	On the download server: Duplicate the download/index.php page and amend it with new release info and links. Duplicate the download/windows/index.php page and amend it with new release info (always keeping the "+"). For major releases only: Create new windows packager script (cloning the current master one and configuring it). Copy the xampp_version_head.php file to xampp_version_XY.php. Create new windows_wpiXY dir by cloning the previous one (HEAD based), configuring build-latest-XY.sh. Edit the stats.php script (in the serverscripts repository), adding the new branch to the versions. It will be automatically deployed.	Integration Lead
9.	✓	✓	In the Tracker... Visit the versions page and make the release, bumping all remaining open bugs to the next point release. This must be done both for the Moodle Project and the Add-ons project. Archive any version > 6 months old. Remove from all screens the custom fields belonging to 100% unsupported branches.	Integration Lead
10.	✓		Create the new "Pull X.Y Branch" and "Pull X.Y Diff URL" custom fields and spread them to all the screens needing them (copy from previous ones). Order them properly on each screen. Reindex Tracker.	Integration Lead
11.	✓		Clone MDL-42929, MDL-42930 and MDL-42931, to be resolved ASAP.	Integration Lead
12.	✓	✓	Add/update the release date, build number and link on the Releases page and date in new version pages.	Integration Lead

Release day

Usually on Monday

#	Major	Minor	Task	Responsibility
1.	✓	✓	The execution of "moodle-package-extract-and-postprocess X" script may be needed if the releases are not going to be published on Monday but another weekday (X is the weekday, (1-7) starting in Monday). By default it happens automatically around 09:00 AM Perth/Australia time.	Integration Lead
2.	✓	✓	Replace the download/index.php page with its updated counterpart.	Integration Lead
3.	✓	✓	Replace the download/windows/index.php page with its updated counterpart.	Integration Lead
4.	✓	✓	Notify all registered sys admins, including security notes with CVE identifiers.	Development Manager
5.	✓		Post about the Major release on the moodle.org News forum	Lead Developer
6.		✓	Post about minor releases on the moodle.org News forum	Development Manager
7.	✓	✓	Post about the release on Twitter and other outlets.	Digital Marketing Specialist
8.	✓		New "X.Y+1dev" branch to be created in AMOS, to have master changes performed there. This needs to be done anytime during the on-sync period.	AMOS Maintainer
9.	✓	✓	Verify, 24h after tagging, that https://moodle.org/dev/ has been updated with new versions. If not, file an urgent mdlsite issue, crons must be running!	Integration Lead
10.	✓		For en and de Moodle Docs, update default redirects, enable email notifications and add version links to https://docs.moodle.org/overview/.	Moodle Docs Maintainer
11.	✓		Go through all points listed under Day of release in New docs version process.	Community Manager
12.	✓		Publish the calendar for next Major release (for the next 6-months period: ~1 month bugfixing and planning, ~4 months of development, ~1 month for QA, candidates/betas/release). Decide the "Code freeze" and "QA begins" dates for the next X.(Y+1) major release and put them in the Moodle development calendar. They will be -5w and -4w before release date respectively. Update upcoming dates on the Roadmap page.	Development Manager
13.	✓	✓	Upgrade all moodle.org and moodle.net sites to latest release version.	System Administrator

1 week after

#	Major	Minor	Task	Responsibility
1.	✓	✓	Publish the X.Y+ packages for download.moodle.org (should be automatic once weeklies are packaged).	Integration Lead
2.	✓	✓	Update the version.php in git to be X.Y.Z+ during the next weekly integration process	Integration Lead
3.	✓	✓	Create a new release notes page for the next minor versions (using the release notes template.)	Development Manager
4.	✓	✓	Add all security advisories to Security news and release notes with links to security advisories	Development Manager
5.	✓	✓	Send a plain text email to the OSS mailing list: oss-security@lists.openwall.com. An appropriate message when sending the issues is... `The following security notifications have now been made public. Thanks to OSS members for their cooperation.` ...followed by the security notes.	Development Manager

1 month after

#	Major	Minor	Task	Responsibility
1.	✓		Publish the X.(Y+1)dev packages for download.moodle.org	Integration Lead

@@ Line 38: / Line 38: @@
 | [https://moodle.org/user/view.php?id=381842&course=5 Michael de Raadt]
 |}
-Updated 18 June 2013.
+Roles updated 18 June 2013.
+<html>
 ==6 weeks prior==
@@ Line 72: / Line 74: @@
 | Check [http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=labels+%3D+qa_test_required qa_test_required-labelled issues] and create new QA tests as required.
 | [[#community|Community Manager]]
+|-
+| 5.
+| style="text-align:center" | &#10003;
+|
+|
+* Remove tests that have been converted to Behat tests from the QA master list.
+* Review tests that cannot be tested on qa.moodle.net by mere mortals and label these with ''test_server_required''.
+| [[#tests|Testing Maintainer]]
 |}
@@ Line 135: / Line 145: @@
 |
 | Tidy up current latest en version of Moodle Docs prior to copying it to create new version wiki as described in [[New docs version process]].
-| [[#community|Community Manager]]
+| [[#docs|Moodle Docs Maintainer]]
 |-
 | 9.
@@ Line 142: / Line 152: @@
 | Prepare a fresh installation of the [http://qamaster.moodle.net QA Master site] based on the beta code to make sure the site is not affected by incremental upgrade steps during the development cycle.
 | [[#qamaster|QA Master Site Maintainer]]
+|-
+| 10.
+| style="text-align:center" | &#10003;
+|
+| Create new QA test cycle and invite community volunteers to start [[QA testing]].
+| [[#community|Community Manager]]
+|-
+| 11.
+| style="text-align:center" | &#10003;
+|
+| Update the [https://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=11454 QA testing dashboard].
+| [[#dev|Development Manager]]
+|-
+| 12.
+| style="text-align:center" | &#10003;
+|
+| Monitor QA fails. Check each fail is real and if so ensure an MDL issue has been created and correctly linked and labelled.
+| [[#tests|Testing Maintainer]]
+|-
+| 13.
+| style="text-align:center" | &#10003;
+|
+| Monitor MDL issues created for QA fails. Add them to the "Must fix for X.Y" list and get a developer to work on the issue immediately.
+| [[#dev|Development Manager]]
 |}
@@ Line 156: / Line 190: @@
 | style="text-align:center" | &#10003;
 |
-| Create new QA test cycle and start [[QA testing]].
+| Prompt developers to begin QA tests marked ''test_server_required''.
-| [[#community|Community Manager]]
+| [[#dev|Development Manager]]
 |-
 | 2.
@@ Line 169: / Line 203: @@
 | style="text-align:center" | &#10003;
 | Check [http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=labels+%3D+docs_required docs_required-labelled issues] and write new documentation, removing the label and commenting in the issue when the work is done.
-|
+| [[#docs|Moodle Docs Maintainer]]
 |-
 | 4.
@@ Line 175: / Line 209: @@
 |
 | Go through all points listed under 3 weeks prior in [[New docs version process]].
-| [[#community|Community Manager]]
+| [[#docs|Moodle Docs Maintainer]]
+|}
+==2 weeks prior==
+{| class="nicetable" style="width:100%"
+|-
+! #
+! Major
+! Minor
+! Task
+! style="width:12%" | Responsibility
+|-
+| 1.
+| style="text-align:center" | &#10003;
+|
+|
+* Prompt developers to complete remaining QA tests.
+* Ensure all QA tests are completed and passed by the end of the week.
+| [[#dev|Development Manager]]
 |}
@@ Line 263: / Line 315: @@
 | style="text-align:center" | &#10003;
 |
-| Check on the "Must fix for 2.x version". Filter out unrealistic issues.
+| Check on the "Must fix for X.Y version". Filter out unrealistic issues.
 | [[#dev|Development Manager]]
 |-
@@ Line 274: / Line 326: @@
 ==Releasing==
-===Package day===
+===Packaging===
 This should happen immediately before the next integration cycle begins on Monday (i.e., some days after last weekly, 2 days prior to official release).
 {| class="nicetable" style="width:100%"

Documentation