Difference between revisions of "Release process"

Jump to: navigation, search
(Update cloned major-release related issues.)
m (4 weeks prior)
 
(327 intermediate revisions by 19 users not shown)
Line 1: Line 1:
==Roles==
+
== 8 weeks prior ==
{| class="nicetable"
+
{| class="table table-striped table-bordered"
 
|-
 
|-
! Role
+
! style="width:20px" | #
! Person responsible
+
! style="width:20px" | Major
 +
! style="width:20px" | Minor
 +
! Task
 +
! style="width:12%" | Responsibility
 
|-
 
|-
| <span id="lead">Lead Developer</span>
+
| 1.
| [https://moodle.org/user/view.php?id=1&course=5 Martin Dougiamas]
+
| style="text-align:center" | &#10003;
 +
|  
 +
| Create an issue to review latest stable version of all third party libraries and add to sprint. The issue should refer to the list at [[Moodle libraries credits]]. The issue can be based on MDL-52393.
 +
| Development Manager
 
|-
 
|-
| <span id="integration">Integration Lead</span>
+
| 2.
| [https://moodle.org/user/view.php?id=3176&course=5 Eloy Lafuente]
+
| style="text-align:center" | &#10003;
 +
|
 +
| Ensure we are running latest/good behat, phpunit and nodejs (npm) versions.
 +
| Integration Team
 
|-
 
|-
| <span id="community">Community Manager</span>
+
| 3.
| [https://moodle.org/user/view.php?id=24152&course=5 Helen Foster]
+
| style="text-align:center" | &#10003;
 +
|
 +
| Confirm external testers daily availability from -6w to release (internally with dev manager and then, externally, with contractors).
 +
| Integration Team
 
|-
 
|-
| <span id="amos">AMOS Maintainer</span>
+
| 4.
| [https://moodle.org/user/view.php?id=1601&course=5 David Mudrák]
+
| style="text-align:center" | &#10003;
 +
 +
| - Move QA tests for new features in old release with automated tests from MDLQA-1 to MDLQA-5249.
 +
- Remind devs:
 +
* To label issues qa_test_required when a new feature/improvement is landing without automated tests. Also add a comment advising exactly what should be covered in the QA test e.g. steps 6-10 in testing instructions.
 +
* The best possible lang strings land at first attempt. Given the proximity of the major release and to facilitate the work of translators and others... the sooner, the better, instead of relying on (late) en_fixes too much.  
 +
- Contact with external testing towards preparing the continuous integration period (-6w to +2w, right now) starting in just 2 weeks.
 +
| Testing Maintainer
 
|-
 
|-
| <span id="docs">Moodle Docs Maintainer</span>
+
| 5.
| [https://moodle.org/user/view.php?id=1601&course=5 David Mudrák]
+
| style="text-align:center" | &#10003;
 +
|
 +
| - Create a "Must fix for X.Y" version in the Tracker and adjust the [https://ci.moodle.org/view/Tracker/job/TR%20-%20Set%20integration%20priority%20to%20one/ "TR - Set integration priority to one"] and [https://ci.moodle.org/view/Tracker/job/TR%20-%20Move%20reopened%20out%20from%20current/ "TR - Move reopened out from current"] jobs in '''all CI servers''' to point to it.
 +
- Apply the following changes to filters and dashboards:
 +
*  Edit the [https://tracker.moodle.org/issues/?filter=21363 All "must fix" issues] filter used both in the release dashboard and to detect wrong uses of must-fix issues. Note that, since 3.7, this filter is fully automated and does not need edition (uses regexp to catch all must fix versions).
 +
* Comment about its creation within HQ, to get people applying for it.
 +
* Verify that these filters ([https://tracker.moodle.org/issues/?filter=18596 1], [https://tracker.moodle.org/issues/?filter=18594 2] and [https://tracker.moodle.org/issues/?filter=18861 3]), used in the [https://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=16582 Release urgent dashboard], are working ok (they should be, automatically based in the filter edited in the previous point).
 +
* Rename [https://tracker.moodle.org/secure/Dashboard.jspa?selectPageId=16582 Release urgent dashboard] to point to incoming release (QA part of the dashboard will not work yet)
 +
| Integration Lead
 +
|}
 +
 
 +
==7 weeks prior==
 +
{| class="table table-striped table-bordered"
 
|-
 
|-
| <span id="plugins">Plugins Directory Maintainer</span>
+
! style="width:20px" | #
| [https://moodle.org/user/view.php?id=1146834&course=5 Aparup Banerjee]
+
! style="width:20px" | Major
 +
! style="width:20px" | Minor
 +
! Task
 +
! style="width:12%" | Responsibility
 
|-
 
|-
| <span id="tests">Testing Maintainer</span>
+
| 1.
| [https://moodle.org/user/view.php?id=122326&course=5 David Monllaó]
+
| style="text-align:center" | &#10003;
 +
|
 +
| Full demo of new code and sign-off for internal HQ projects. Decide which projects will be completed by the code freeze.
 +
| Lead Developer
 
|-
 
|-
| <span id="qamaster">QA Master Site Maintainer</span>
+
| 2.
| [https://moodle.org/user/view.php?id=24152&course=5 Helen Foster]
+
| style="text-align:center" | &#10003;
 +
|
 +
| Check [https://tracker.moodle.org/issues/?jql=labels%20%3D%20qa_test_required%20AND%20status%20%3D%20Closed closed qa_test_required-labelled issues] and create new QA tests as required.
 +
| Testing Maintainer
 
|-
 
|-
| <span id="marketing">Digital Marketing Specialist </span>
+
|}
| [https://moodle.org/user/view.php?id=1622371 X.Y. Ng]
+
 
 +
==6 weeks prior==
 +
{| class="table table-striped table-bordered"
 +
|-
 +
! style="width:20px" | #
 +
! style="width:20px" | Major
 +
! style="width:20px" | Minor
 +
! Task
 +
! style="width:12%" | Responsibility
 +
|-
 +
| 1.
 +
| style="text-align:center" | &#10003;
 +
|
 +
| The [https://docs.moodle.org/dev/Integration_Review#During_continuous_integration.2FFreeze.2FQA_period Continuous Integration] period begins. Warn about it everywhere (telegram, exposed posts...).
 +
 
 +
Rolling (on demand, beta, rc... all them together with stable weeklies) happens often (Tuesday & Friday are the usual days). All the team is on integration 100% since this week and until the end of continuous.
 +
| Integration Lead
 
|-
 
|-
| <span id="sysadmin">System Administrator</span>
+
| 2.
| [https://moodle.org/user/view.php?id=1532884&course=5 Matthew Spurrier]
+
| style="text-align:center" | &#10003;
 +
|
 +
| 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
 
|-
 
|-
| <span id="dev">Development Manager</span>
+
| 3.
| [https://moodle.org/user/view.php?id=381842&course=5 Michael de Raadt]
+
| style="text-align:center" | &#10003;
 +
|
 +
| Warn external developers about the impending code freeze in a post to the [http://moodle.org/mod/forum/view.php?id=55 General developer forum]. ([https://moodle.org/mod/forum/discuss.php?d=225854 example])
 +
| Development Manager
 
|}
 
|}
Updated 18 June 2013.
 
  
==6 weeks prior==
+
==5 weeks prior==
{| class="nicetable" style="width:100%"
+
{| class="table table-striped table-bordered"
 
|-
 
|-
! #
+
! style="width:20px" | #
! Major
+
! style="width:20px" | Major
! Minor
+
! style="width:20px" | Minor
 
! Task
 
! Task
 
! style="width:12%" | Responsibility
 
! style="width:12%" | Responsibility
Line 52: Line 113:
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
|  
 
|  
| 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.
+
| Confirm the code freeze by replying to the previous warning in the [http://moodle.org/mod/forum/view.php?id=55 General developer forum].
| [[#integration|Integration Lead]]
+
| Development manager
 
|-
 
|-
 
| 2.
 
| 2.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
|  
 
|  
| Create a "Must fix for X.Y" version in the tracker.
+
| This week, once the integration server has ended with Monday's job [https://ci.moodle.org/view/Tracker/job/TR%20-%20Move%20awaiting%20issues%20to%20current%20integration/ moving issues to integration] (after 11:00 UTC), the following jobs have to be disabled:
| [[#integration|Integration Lead]]
+
* [https://ci.moodle.org/view/Tracker/job/TR%20-%20Move%20awaiting%20issues%20to%20current%20integration/ Move awaiting issues to current integration].
 +
* [https://ci.moodle.org/view/Tracker/job/TR%20-%20Delay%20awaiting%20issues/ Delay awaiting issues].
 +
(issues will be manually picked for integration until the post-release "On Sync" period ends, usually 2 weeks after release.
 +
 
 +
Review all the new features and improvements so, everything "unrelated" with the release, is given the "integration_held" label. That means that will be ignored unless there is an [https://docs.moodle.org/dev/Integration_Review#During_continuous_integration.2FFreeze.2FQA_period unhold request process] started on them.
 +
 
 +
Dev leaders promptly vote on held issues labelled with unhold_requested label and decide whether they can be allowed to break the freeze
 +
| Integration Lead
 
|-
 
|-
 
| 3.
 
| 3.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
|  
 
|  
| Freeze stable development and post in the [http://moodle.org/mod/forum/view.php?id=55 General developer forum] to inform everyone of the freeze. ([https://moodle.org/mod/forum/discuss.php?d=225854 example])
+
| Prepare a fresh installation of the [http://qa.moodle.net QA site] based on the beta code to make sure the site is not affected by incremental upgrade steps during the development cycle.
| [[#dev|Development Manager]]
+
| QA Master Site Maintainer
 
|-
 
|-
 
| 4.
 
| 4.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
|  
 
|  
| 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.
+
| Write documentation on new features in the dev docs, adding a link to it from the tracker issue, together with the label ''docs_required''. The documentation will then be transferred to the new en version wiki when it is set up (3 weeks prior) and polished, with screenshots added.
 +
| Developers, Development manager to remind
 +
|-
 +
| 5.
 +
| style="text-align:center" | &#10003;
 
|  
 
|  
 +
| Begin reviewing [https://lang.moodle.org/mod/forum/view.php?id=7 new and changed English language strings] ready for en_fix to be merged 2 weeks prior.
 +
| English fixes lang pack maintainer
 
|}
 
|}
  
 
==4 weeks prior==
 
==4 weeks prior==
{| class="nicetable" style="width:100%"
+
{| class="table table-striped table-bordered"
 
|-
 
|-
! #
+
! style="width:20px" | #
! Major
+
! style="width:20px" | Major
! Minor
+
! style="width:20px" | Minor
 
! Task
 
! Task
 
! style="width:12%" | Responsibility
 
! style="width:12%" | Responsibility
Line 87: Line 161:
 
|  
 
|  
 
| Start working on the [[Releases|release notes]] ([[Release notes template|template]]) of the upcoming version.
 
| Start working on the [[Releases|release notes]] ([[Release notes template|template]]) of the upcoming version.
| [[#dev|Development Manager]]
+
| Development Manager
 
|-
 
|-
 
| 2.
 
| 2.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
|  
 
|  
| Release normal weeklies but with these changes in the master branch:
+
| Create issues for adding User tours for new features in the upcoming version. Review existing tours and remove very old ones
* version.php: Move to $maturity = MATURITY_BETA and $release  = 'X.Ybeta (Build:xxxxxxxx)'
+
| Development Manager
* 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|Integration Lead]]
 
 
|-
 
|-
 
| 3.
 
| 3.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
|  
 
|  
| (Optionally) Announce Beta release in forums (ideally once packages are available).
+
| Beta release (The Moodle release tool - mdlrelease - manages it): Release normal weeklies but with these changes in the master branch being considered all the time, until we are feature complete (can happen @ -4w - ideally - but also later):
| [[#integration|Integration Lead]]
+
* 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)
 +
* Automatic: Confirm packages are available under download.moodle.org (and windows).
 +
* Once the beta is available create the "[https://docs.google.com/spreadsheets/d/1TcMJT3o2Cnyq006lmLWrXJeNQQzyNXz2E_Vbc8ff5EE/edit?usp=sharing|Release testing matrix for X.Y.0]" and share it @ HQ & Dev. chat.
 +
* (Optionally) Announce Beta release in forums (ideally once packages are available).
 +
| Integration Lead
 
|-
 
|-
 
| 4.
 
| 4.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
|  
 
|  
| Review documentation for all issues with labels "[http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=labels+%3D+dev_docs_required dev_docs_required]", removing this label when relevant docs are updated.
+
| Clone MDL-66881 for the X.Y release, adding there all the debugging / PHP notices happening in the web server logs while running tests.
|  
+
| Integration Lead
 
|-
 
|-
 
| 5.
 
| 5.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
|  
 
|  
| During the QA weeks integration becomes continuous; release STABLE weeklies normally but master release as often as possible (or on demand).
+
| Release candidates release (The Moodle release tool - mdlrelease - manages it): At some points (between beta to final release) produce release candidates (Z = 1, 2, 3..), which are normal builds with the following changes:
| [[#integration|Integration Lead]]
+
* 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)
 +
* Automatic: Confirm packages are available under download.moodle.org (and windows).
 +
* Upgrade all the Moodle CI sites to recent release candidate by configuring the "Moodle CI Auto Upgrade" job in all them.
 +
| Integration Lead
 
|-
 
|-
 
| 6.
 
| 6.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
|  
 
|  
| At some points produce release candidates (Z = 1, 2, 3..), which are normal builds with:
+
| Add a new version in the Plugins Directory with the version's name and the beta release version build number (https://moodle.org/plugins/admin/softwareversions.php).
* version.php: Move to $maturity = MATURITY_RC and $release = 'X.YrcZ (Build:xxxxxxxx)'
+
* Any standard plugins being retired from the release can transition to Add-on (that supports this release and/or any previous ones) now.
* tag git repo with: "vX.Y.0-rcZ"  (and MOODLE_XY_RCZ as description and CVS tag)
+
* These plugins currently collect at https://moodle.org/plugins/browse.php?list=contributor&id=1532512
* Make packages available under download.moodle.org (and Windows).
+
| Plugins Liaison
| [[#integration|Integration Lead]]
 
 
|-
 
|-
 
| 7.
 
| 7.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
|  
 
|  
| 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).
+
| Push any plugins to the plugins database which were previously a part of core.
| [[#plugins|Plugins Directory Maintainer]]
+
| Plugins Liaison
 
|-
 
|-
 
| 8.
 
| 8.
Line 135: Line 214:
 
|  
 
|  
 
| 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]].
 
| 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 Manager
 
|-
 
|-
 
| 9.
 
| 9.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
|  
 
|  
| 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.
+
| Create new QA test cycle and post in development forum about [[QA testing]].
| [[#qamaster|QA Master Site Maintainer]]
+
| Testing Maintainer
 +
|-
 +
| 10.
 +
| style="text-align:center" | &#10003;
 +
|
 +
| Invite community volunteers to start [[QA testing]].
 +
| Community Manager
 +
|-
 +
| 11.
 +
| style="text-align:center" | &#10003;
 +
|
 +
| Modify [https://tracker.moodle.org/issues/?filter=11824 Current QA cycle filter] to link to the new QA test cycle
 +
| Testing Maintainer
 +
|-
 +
| 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.
 +
| 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.
 +
| Development Manager
 
|}
 
|}
  
 
==3 weeks prior==
 
==3 weeks prior==
{| class="nicetable" style="width:100%"
+
{| class="table table-striped table-bordered"
 
|-
 
|-
! #
+
! style="width:20px" | #
! Major
+
! style="width:20px" | Major
! Minor
+
! style="width:20px" | Minor
 
! Task
 
! Task
 
! style="width:12%" | Responsibility
 
! style="width:12%" | Responsibility
Line 155: Line 259:
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
|  
 
|  
| Create new QA test cycle and start [[QA testing]].
+
| Prompt developers to begin QA tests marked [https://tracker.moodle.org/issues/?jql=filter%20%3D%2011824%20AND%20labels%20IN%20(test_server_required%2C%20credentials_required)%20AND%20status%20IN%20(OPEN%2C%20FAILED)%20AND%20comment%20~%20external_skipped ''test_server_required'' and ''credentials_required'' and external_skipped].
| [[#community|Community Manager]]
+
| Development Manager
 
|-
 
|-
 
| 2.
 
| 2.
Line 162: Line 266:
 
|  
 
|  
 
| Create new en and de Moodle Docs version wikis.
 
| Create new en and de Moodle Docs version wikis.
 +
| Moodle Docs Maintainer
 +
|-
 +
| 3.
 +
| style="text-align:center" | &#10003;
 +
| style="text-align:center" | &#10003;
 +
| Check [https://tracker.moodle.org/issues/?jql=labels%20%3D%20docs_required%20AND%20status%20%3D%20Closed docs_required-labelled issues] and write new documentation, removing the label and commenting in the issue when the work is done.
 +
| Community Manager
 +
|-
 +
| 4.
 +
| style="text-align:center" | &#10003;
 +
|
 +
| Go through all points listed under 3 weeks prior in [[New docs version process]].
 +
| Community Manager
 +
|-
 +
| 5.
 +
| style="text-align:center" | &#10003;
 +
|
 +
| Review issues with labelled with [https://tracker.moodle.org/issues/?filter=11824&jql=labels%20in%20%28dev_docs_required%29%20AND%20resolution%20%3D%20fixed%20ORDER%20BY%20assignee%20ASC%2C%20created%20ASC dev_docs_required], prompting assigned developers to create/update this documentation and remove this label when relevant docs are updated.
 +
| Development Manager
 +
|-
 +
| 6.
 +
| style="text-align:center" | &#10003;
 +
| style="text-align:center" | &#10003;
 +
| Verify how everything is going and, before the end of the week, decide (dev leaders & integrators) if there are real reasons for delaying any release. Proceed to communicate any delay ASAP to both developers & partners. Don't forget to update calendars and tracker releases with the new dates.
 +
| Development Manager
 +
|}
 +
 +
==2 weeks prior==
 +
{| class="table table-striped table-bordered"
 +
|-
 +
! style="width:20px" | #
 +
! style="width:20px" | Major
 +
! style="width:20px" | Minor
 +
! Task
 +
! style="width:12%" | Responsibility
 +
|-
 +
| 1.
 +
| style="text-align:center" | &#10003;
 +
|
 +
|
 +
Check the number of open QA tests. Depending on the amount of work involved, encourage HQ developers to assist from the start of the week or later in the week in order to achieve the target of 100% pass rate by the end of the week.
 +
| Development Manager
 +
|-
 +
| 2.
 +
| style="text-align:center" | &#10003;
 
|  
 
|  
 +
|
 +
Create MDLSITE issue to ensure all prototype.moodle.net sites which are no longer relevant (part of release) are removed from prototype.moodle.net
 +
| Development Manager
 
|-
 
|-
 
| 3.
 
| 3.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| 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.
+
| Merge fixes from en_fix pack and then integrate them.
 +
| AMOS Maintainer
 
|-
 
|-
 
| 4.
 
| 4.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
|  
+
|
| Go through all points listed under 3 weeks prior in [[New docs version process]].
+
| Give Partners complete brandable Marketing pack for release including list and description of major new features.
|
+
| Marketing Manager
 +
|-
 +
| 5.
 +
| style="text-align:center" | &#10003;
 +
|
 +
| Label (ui_change) in the Tracker all pending issues having '''noticeable UI modifications''' and track them in the "[https://docs.google.com/spreadsheets/d/18xZf9OgKrndi7CwSTwjwjF_rzGYCWFuGjNNaaDVZDM4/edit?usp=sharing Late landing UI changes]" sheet, in order to have all the associated docs, screenshots, videos under control. The Integration and Documentation people will try to '''keep the sheet updated until release'''.
 +
|Integration Lead
 
|}
 
|}
  
 
==1 week prior==
 
==1 week prior==
{| class="nicetable" style="width:100%"
+
{| class="table table-striped table-bordered"
 
|-
 
|-
! #
+
! style="width:20px" | #
! Major
+
! style="width:20px" | Major
! Minor
+
! style="width:20px" | Minor
 
! Task
 
! Task
 
! style="width:12%" | Responsibility
 
! style="width:12%" | Responsibility
Line 189: Line 348:
 
|  
 
|  
 
| Clone as many filters as needed in the Tracker, modifying them to point to the new, upcoming, branch (keeping same perms, title...).  
 
| Clone as many filters as needed in the Tracker, modifying them to point to the new, upcoming, branch (keeping same perms, title...).  
| [[#integration|Integration Lead]]
+
| Integration Lead
 
|-
 
|-
 
| 2.
 
| 2.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| Create new minor version X.Y.Z+1 in the Tracker (MDL and CONTRIB). Archive any version > 6 months old.
+
| Create new minor version X.Y.Z+1 in the Tracker (MDL and CONTRIB). Archive any version > 6 months old, verifying that [https://tracker.moodle.org/issues/?jql=project%3DMDL%20AND%20status%20!%3D%20Closed%20AND%20fixVersion%20%3D%20VERSION_TO_ARCHIVE there aren't open issues using that version].
| [[#integration|Integration Lead]]
+
| Integration Lead
 
|-
 
|-
 
| 3.
 
| 3.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
|  
 
|  
| Clone MDL-39434 and bump all versions, requires and dependencies along all plugins in codebase to current date.
+
| Clone MDL-65571 and bump all versions, requires and dependencies along all plugins in codebase to planned release dates.
| [[#integration|Integration Lead]]
+
| Integration Lead
 
|-
 
|-
 
| 4.
 
| 4.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| Post a "Heads-up" message on the [http://partners.moodle.com/mod/forum/view.php?id=2 Partners forum] and [http://moodle.org/mod/forum/view.php?id=55 General Developer forum].
+
| Post a "Heads-up" message on the [http://moodle.org/mod/forum/view.php?id=55 General Developer forum].
| [[#dev|Development Manager]]
+
| Development Manager
 
|-
 
|-
 
| 5.
 
| 5.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| Post a "Heads-up" message on Twitter and other outlets.
+
| Post a "Heads-up" message on the [https://partners.moodle.com/mod/forum/view.php?id=147 Partners forum].
| [[#marketing|Digital Marketing Specialist]]
+
| Security Officer
 
|-
 
|-
 
| 6.
 
| 6.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| Merge fixes from en_fix pack and then integrate them.
+
| Post a "Heads-up" message on Twitter and other outlets.
| [[#amos|AMOS Maintainer]]
+
| Marketing Officer
 
|-
 
|-
 
| 7.
 
| 7.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
|  
+
| style="text-align:center" | &#10003;
| In https://github.com/moodlehq/moodle-behat-extension project:
+
| Identify security issues that need to be integrated using the [https://tracker.moodle.org/issues/?filter=21712 security issues under integration filter] (includes held, being integrated and ready issues).
* For the new stable version:
+
* Integrate from provided patches into supported branches (including branches supported only for security issues).
*# Create a MOODLE_XY_STABLE branch from master
+
* Ensure security issues are given priority in weekly integration and testing. Note that the --weekly releases to be performed this week are 100% normal and cover the standard (supported) branches. security branches will come as part of the release process later in the week.
*# 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
+
| Integration Lead
*# 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).
 
| [[#tests|Testing Maintainer]]
 
 
|-
 
|-
 
| 8.
 
| 8.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| Identify security issues that need to be integrated using the [http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=labels+%3D+security_held security_held label].
+
| Collect security issues into a clone of the [https://tracker.moodle.org/issues/?jql=component%20%3D%20%22Security%20Alert%22%20AND%20project%20%3D%20MDL%20AND%20level%20is%20not%20EMPTY%20AND%20summary%20~%20%22security%20advisories%22%20ORDER%20BY%20updated%20DESC last advisory in the list] to prepare for release of Security Advisories.
* Integrate from provided patches into supported branches (including branches supported only for security issues).
+
* Determine which security issues will be integrated.
* Ensure security issues are given priority in weekly integration and testing.  
+
* Request CVE Identifiers by emailing issue descriptions to [mailto:secalert@redhat.com secalert@redhat.com] with a message like... <tt> 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.</tt> The email subject should include the characters <tt>[vs]</tt>. The format needs to be plain text or encrypted. When granted CVE Identifiers, our issues should appear in the [http://cve.mitre.org/cve/cve.html CVE list]. More [http://oss-security.openwall.org/wiki/mailing-lists/distros instructions] are available (since 2015 we request identifiers from redhat and not from distros).
| [[#integration|Integration Lead]]
+
* Post security issues as a reply to the "Heads-up" message on the [https://partners.moodle.com/mod/forum/view.php?id=147 Partners forum].
 +
| Security Officer
 
|-
 
|-
 
| 9.
 
| 9.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| Collect security issues into a clone of MDL-39530 to prepare for release of Security Advisories.
+
| Review and complete the [[Releases|release notes]], making sure that issues have easily understandable summaries. Aim to have the release notes mostly complete on the Wednesday before release, and fully complete on the Friday, to give translators time to translate them.
* Determine which security issues will be integrated.
+
* Ensure all issues labelled with "ui_change", "api_change" and "release_notes" are listed as UI changes, functional changed and fixes/improvements respectively in the release notes.
* Request CVE Identifiers by emailing issue descriptions to [mailto:distros@vs.openwall.org distros@vs.openwall.org] with a message like... <tt> 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.</tt> The email subject should include the characters <tt>[vs]</tt>. The format needs to be plain text or encrypted. When granted CVE Identifiers, our issues should appear in the [http://cve.mitre.org/cve/cve.html CVE list]. More [http://oss-security.openwall.org/wiki/mailing-lists/distros instructions] are available.
+
| Development Manager
* Post security issues as a reply to the "Heads-up" message on the [http://partners.moodle.com/mod/forum/view.php?id=2 Partners forum].
 
| [[#dev|Development Manager]]
 
 
|-
 
|-
 
| 10.
 
| 10.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| style="text-align:center" | &#10003;
+
|  
| Review and complete the [[Releases|release notes]] for the upcoming minor versions.
+
| Check on the "Must fix for X.Y version". Filter out unrealistic issues.
* Ensure all issues labelled with "ui_change" or "api_change" are listed as functional or API changes respectively in the release notes.
+
| Development Manager
| [[#dev|Development Manager]]
 
 
|-
 
|-
 
| 11.
 
| 11.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 +
 +
| Upgrade moodle.org to beta release
 +
|
 +
|-
 +
| 12.
 +
|
 +
|  style="text-align:center" | &#10003;
 +
| Upgrade moodle.org and all other Moodle community sites (next sites first, then production) - Friday before release if not before
 +
|
 +
|-
 +
| 13.
 +
|  style="text-align:center" | &#10003;
 
|  
 
|  
| Check on the "Must fix for 2.x version". Filter out unrealistic issues.
+
| Prepare pull requests for CI Repositories:
| [[#dev|Development Manager]]
+
* MR1: Create a new version, with unit tests, in Jobs repository ([https://git.in.moodle.com/integration/nightlyjobs/merge_requests/1 see example from 3.5 release])
 +
* MR2: Create a new symlink for the version in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository ([https://github.com/moodlehq/moodle-ci-runner/commit/405c7739d0b92095c738d386ecd7e4f059557edd see example from 3.7 release])
 +
* MR3: Configure CIs to skip language upgrade in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository ([https://github.com/moodlehq/moodle-ci-runner/commit/8bbcbf0a05c15b15c96d8b743b50c4919f46bb80 see example from 3.7 release])
 +
* MR4: Configure CIs to stop skipping language upgrade in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository for after on-sync ([https://github.com/moodlehq/moodle-ci-runner/pull/1 see example from 3.7 release]) -- Note: This change should be based on the previous.
 +
| Testing Maintainer
 
|-
 
|-
| 12.
+
| 14.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
|  
 
|  
| Upgrade moodle.org (test server first, then production)
+
| Go through all points listed under 1 week prior in [[New docs version process]].
| [[#sysadmin|System Administrator]]
+
| Community Manager
 +
|-
 
|}
 
|}
  
==Day of release==
+
==Releasing==
 
===Packaging===
 
===Packaging===
{| class="nicetable" style="width:100%"
+
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="table table-striped table-bordered"
 
|-
 
|-
! #
+
! style="width:20px" | #
! Major
+
! style="width:20px" | Major
! Minor
+
! style="width:20px" | Minor
 
! Task
 
! Task
 
! style="width:12%" | Responsibility
 
! style="width:12%" | Responsibility
Line 284: Line 454:
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| Make sure there are no real blockers introduced in the last weekly (install / upgrade ...)
+
| Check list:
| [[#integration|Integration Lead]]
+
* Make sure there are no real blockers introduced in the last weekly (install / upgrade ...).
 +
* Confirm that the latest [https://tracker.moodle.org/issues/?jql=summary%20~%20%22en_fix%22%20order%20by%20createdDate%20desc en_fix changes]have been generated and integrated.
 +
* Verify that [https://tracker.moodle.org/issues/?jql=text%20~%20%22%2BPrepare%20%2Bsecurity%20%2Badvisories%20%2Bfriends%22%20ORDER%20BY%20updated%20DESC all security issues] have been integrated and there are not leftovers in the security area (but for delayed majors, where some security issues may have been introduced along the delay and they will be postponed to next minors).
 +
| Integration Lead
 
|-
 
|-
 
| 2.
 
| 2.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| Verify all unit tests and integration tests have passed.
+
| Verify all unit tests and integration tests have passed (check all current CI servers in use).
| [[#integration|Integration Lead]]
+
| Integration Lead
 
|-
 
|-
 
| 3.
 
| 3.
Line 297: Line 470:
 
|  
 
|  
 
| Verify QA tests have passed.
 
| Verify QA tests have passed.
| [[#integration|Integration Lead]]
+
| Integration Lead
 
|-
 
|-
 
| 4.
 
| 4.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| For major releases only:  
+
| Timing prerequisites (don't continue with the process if not within the time window!):
* 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.
+
# Latest weeklies before the minor/major releases must be done (moodle-package-extract-and-postprocess email should confirm this has happened around 09:00 Australia/Perth).
 +
# Minor and major releases can be packaged at any time within the 96 hours before the automatic releasing time (Monday 09:00 Australia/Perth). And always, at very least, 4 hours before then (to allow the server to prepare all the stuff).
 +
(in practice, this means that the packaging of minor/major releases must be done, assuming that weeklies were rolled normally on Thursday, between Friday 09:00 and Monday 05:00 (Australia/Perth times). Breaking any of these rules will require manual operation in the server, forcing repackaging and releasing.
 +
 
 
Follow the "mdlrelease" steps:
 
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!
+
* Run the '''prerelease.sh''' script to generate the target minor (--type minor) and major (--type major) releases and their corresponding tags. Pay attention to the complete output of the process: permissions, svg, travis changes (only for majors)... Triple verify all changes are correct! (can use the --show option to inspect them). Follow the on-screen instructions.
* Push changes to integration.git
+
* Push changes to integration.git (but tags).
* Once CI servers have ended and all jobs have passed, run the '''release.sh''' script to apply the changes to moodle.git
+
For major releases only:
| [[#integration|Integration Lead]]
+
* Run the '''prerelease.sh''' script (--type back-to-dev) to move master to next X.Y+1 development version/branch.
 +
* 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 #12 below).
 +
* Configure "mdlrelease" (config.sh) to know about the new MOODLE_XY stable branch.
 +
* Update the old CI server(s) by cloning all the "master" jobs to a new "MXY" view (trick: do it down-top, way easier). Adjust "master" compare DB jobs to check for upgrade from MOODLE_XY_STABLE. Don't forget to re-chain the jobs properly. Run them.
 +
* Update the new CI infrastructure:
 +
** MR1: Merge pull request for new version in [https://git.in.moodle.com/integration/nightlyjobs CI Jobs Repository]
 +
** MR2: Merge pull request for symlink in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository.
 +
** MR3: Merge pull request for skipping the language upgrade in [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository.
 +
** Clone all the "B - master" jobs to a new "B - XY" view (there is a [https://ci.moodle.org/view/maintenance/job/MAINT%20-%20Clone%20jobs%20from%20master%20view/ maintenance job] to perform the operation).
 +
Both with minors and majors, continue with the "mdlrelease" steps:
 +
* Once CI servers have ended and all jobs have passed, push tags and run the '''release.sh''' script to apply the changes to moodle.git.
 +
* If needed configure "mdlrelease" (config.sh) to get rid of any unsupported version and adjust stable and security branches. Make a pull request with the changes.
 +
* Don't forget the "[https://github.com/moodlehq/mdlrelease/#after-the-release After the release]" tasks.
 +
| Integration Lead
 
|-
 
|-
 
| 5.
 
| 5.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| Post a "git repos updated & tagged" message on the [http://partners.moodle.com/mod/forum/view.php?id=2 Partner forum]
+
| Post a "git repos updated & tagged" message on the [https://partners.moodle.com/mod/forum/view.php?id=147 Partner forum]
| [[#integration|Integration Lead]]
+
| Integration Lead
 
|-
 
|-
 
| 6.
 
| 6.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
|
 
|
| 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
+
| In the [https://github.com/moodlehq/moodle-performance-comparison performance comparison repository], set the new release commit hash as $basecommit in the master branch and create a new MOODLE_XY_STABLE branch from it. ([https://github.com/moodlehq/moodle-performance-comparison/commit/fd57c0caa3d1b909f64cd3a8685e9d6db0e1d434 example]).
| [[#tests|Testing Maintainer]]
+
| Testing Maintainer
 
|-
 
|-
 
| 7.
 
| 7.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| Wait for the automated moodle-package to finish building for all versions. Verify the process has ended successfuly (email).
+
| Wait for the automated (every 2 hours) moodle-package to finish building for all versions. Verify the process has ended successfully (email).
For major releases only:
+
| Integration Lead
* Use the '''prerelease.sh''' script (--type back-to-dev) to move master to next X.Y+1 development version/branch.
 
| [[#integration|Integration Lead]]
 
 
|-
 
|-
 
| 8.
 
| 8.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| style="text-align:center" | &#10003;
+
|
| 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).
 
* 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.
 
* Create new windows_wpiXY dir by cloning the previous one (HEAD based), configuring build-latest-XY.sh.
* Edit the stats script, adding the new branch to the versions.
+
* Edit the stats.php script (in the moodle-local_downloadmoodleorg repository), adding the new branch to the versions. Push it. Next time the plugin is deployed (normally 1 week after release, aprox.) the stats will start showing the new branch statistics.
| [[#integration|Integration Lead]]
+
| Integration Lead
 
|-
 
|-
 
| 9.
 
| 9.
Line 347: Line 530:
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| In the Tracker...
 
| 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 [http://tracker.moodle.org/secure/project/ViewProject.jspa?pid=10011 Moodle Project] and the [http://tracker.moodle.org/secure/project/ViewProject.jspa?pid=10033 Add-ons project]. Archive any version > 6 months old.
+
* Visit the versions page and make the release, bumping all remaining open bugs to the next point release. If there is not next (end of support), clean that version from all the issues having it as "Fix for". This must be done both for the [http://tracker.moodle.org/secure/project/ViewProject.jspa?pid=10011 Moodle Project] and the [http://tracker.moodle.org/secure/project/ViewProject.jspa?pid=10033 Plugins project]. Archive any version > 6 months old, verifying that [https://tracker.moodle.org/issues/?jql=project%3DMDL%20AND%20status%20!%3D%20Closed%20AND%20fixVersion%20%3D%20VERSION_TO_ARCHIVE there aren't open issues using that version].
* Remove from all screens the custom fields belonging to 100% unsupported branches.  
+
* Remove from all screens the custom fields belonging to 100% unsupported branches.
| [[#integration|Integration Lead]]
+
For major releases only:
 +
* Release and archive the [https://tracker.moodle.org/issues/?jql=affectedVersion%20~%20%22must%20fix%20for*%22%20OR%20fixVersion%20~%20%22must%20fix%20for*%22 "Must fix for X.Y" versions], it must be empty to do so.
 +
| Integration Lead
 
|-
 
|-
 
| 10.
 
| 10.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
|  
 
|  
| 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). Reindex Tracker. Order them properly on each screen. Hide from all screens the custom fields belonging to 100% unsupported branches.
+
|
| [[#integration|Integration Lead]]
+
* 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. Re-index Tracker.
 +
* In the CI server edit the [http://integration.moodle.org/view/tracker/job/Tracker%20-%20CI%20-%20Bulk%20precheck%20issues/ "Bulk precheck issues"] and [https://ci.moodle.org/view/Tracker/job/TR%20-%20Pre-launch%20DEV%20jobs%20(awaiting_integration)/ "Pre-launch DEV jobs (awaiting_integration)"] jobs to make them meet the new "Pull X.Y Branch" field created.
 +
* Edit the "Tracker - CI - Check marked as integrated" jobs in both servers ([https://ci.moodle.org/view/Tracker/job/TR%20-%20Check%20marked%20as%20integrated/ 1], [http://ci7.stronk7.com:81/view/tracker/job/TR%20-%20Check%20marked%20as%20integrated/ 2]) to configure the master version to point to XY+1.
 +
| Integration Lead
 
|-
 
|-
 
| 11.
 
| 11.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| Add/update the release date, build number and link on the [[Releases|Releases page]] and date in new version pages.
+
| In the Tracker...
| [[#integration|Integration Lead]]
+
For major releases only:
 +
* Create the new "X.Y regressions" version to be applied to every issue found to be a recent problem introduced by the major release. These issues should get priority after release.
 +
* Adjust the filters [https://tracker.moodle.org/issues/?filter=17528 Latest regressions] and [https://tracker.moodle.org/issues/?filter=12738 High Priority Bugs].
 +
For all releases:
 +
* Verify how the "X.Y regressions" versions [https://tracker.moodle.org/issues/?jql=project%20%3D%20MDL%20AND%20resolution%20%3D%20Unresolved%20AND%20affectedVersion%20in%20(versionMatches(%22.*regressions%22)) are going] and ping Development Managers about. Package and archive them once empty.
 +
| Integration Lead
 +
|-
 +
| 12.
 +
| style="text-align:center" | &#10003;
 +
|
 +
| Clone MDL-65643 and MDL-65644, to be resolved ASAP.
 +
| Integration Lead
 +
|-
 +
| 13.
 +
| style="text-align:center" | &#10003;
 +
|
 +
|
 +
* Create the new MOODLE_XY_STABLE and lastbased-MOODLE_XY_STABLE branches in the security repo (branching from the just created upstream MOODLE_XY_STABLE branch).
 +
* Cherry pick any security commit present in the security repository's master branch to the new MOODLE_XY_STABLE branch (note that normally there should not be any, see point #1 check list above).
 +
* Verify the new security jobs exist for the new branch and check it's working in all servers, keeping only enabled the public one.
 +
| Integration Lead
 +
|-
 +
| 14.
 +
| style="text-align:center" | &#10003;
 +
|
 +
| Protect the MOODLE_XY_STABLE branches in github interface to prevent non-FF accidents ( MDLSITE-4183 )
 +
| Integration Lead
 +
|-
 +
| 15.
 +
| style="text-align:center" | &#10003;
 +
|
 +
| The "[https://tracker.moodle.org/issues/?filter=13669 integration_held]" label will be removed '''only''' [https://tracker.moodle.org/issues/?filter=13669&jql=project%20%3D%20MDL%20AND%20type%20in%20(bug%2C%20task)%20AND%20status%20%3D%20%22Waiting%20for%20integration%20review%22%20AND%20%22Currently%20in%20integration%22%20is%20EMPTY%20AND%20labels%20in%20(integration_held)%20ORDER%20BY%20%22Integration%20priority%22%20DESC%2C%20priority%20DESC%2C%20votes%20DESC%2C%20%22Last%20comment%20date%22%20ASC from '''bug issues''' awaiting integration]; they correspond to last-week bugs that were held because of them being unrelated with the release. Now they can be processed, under on-sync rules. Standard message will be used to explain the un-hold.
 +
| Integration Lead
 
|}
 
|}
  
===Release===
+
===Release day===
{| class="nicetable" style="width:100%"
+
Usually on Monday
 +
{| class="table table-striped table-bordered"
 
|-
 
|-
! #
+
! style="width:20px" | #
! Major
+
! style="width:20px" | Major
! Minor
+
! style="width:20px" | Minor
 
! Task
 
! Task
 
! style="width:12%" | Responsibility
 
! style="width:12%" | Responsibility
Line 376: Line 597:
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| 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).
+
| 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|Integration Lead]]
+
| Integration Lead
 
|-
 
|-
 
| 2.
 
| 2.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| Replace the download/index.php page with its updated counterpart.
+
| Verify release status, download pages and windows packages.
| [[#integration|Integration Lead]]
+
| Integration Lead
 
|-
 
|-
 
| 3.
 
| 3.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| Replace the download/windows/index.php page with its updated counterpart.
+
| If needed, modify the downloads cfg script (serverscripts) to decide about branches status, master visibility and windows availability. Push changes, will be autodeployed in a few minutes.
| [[#integration|Integration Lead]]
+
| Integration Lead
 
|-
 
|-
 
| 4.
 
| 4.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| Notify all registered sys admins, including security notes with CVE identifiers.
+
| Add/update the release date, build number and link on the [[Releases|Releases page]] and date in new version pages.
| [[#dev|Development Manager]]
+
| Integration Lead
 
|-
 
|-
 +
 
| 5.
 
| 5.
 +
| style="text-align:center" | &#10003;
 +
| style="text-align:center" | &#10003;
 +
| Notify all registered sys admins, including security notes with CVE identifiers, using the [http://lists.moodle.org/ mailing list server].
 +
| Security Officer
 +
|-
 +
| 6.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
|  
 
|  
 
| Post about the Major release on the [http://moodle.org/news/ moodle.org News forum]
 
| Post about the Major release on the [http://moodle.org/news/ moodle.org News forum]
| [[#lead|Lead Developer]]
+
| Lead Developer
 
|-
 
|-
| 6.
+
| 7.
 
|  
 
|  
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| Post about minor releases on the [http://moodle.org/news/ moodle.org News forum]
 
| Post about minor releases on the [http://moodle.org/news/ moodle.org News forum]
| [[#dev|Development Manager]]
+
| Development Manager
|-
 
| 7.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| Post about the release on Twitter and other outlets.
 
| [[#marketing|Digital Marketing Specialist]]
 
 
|-
 
|-
 
| 8.
 
| 8.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
|  
 
|  
| AMOS needs new "X.Y+1dev" branch to be created, to have master changes performed there.
+
| New "X.Y+1dev" branch to be created in AMOS, to have master changes performed there. New install_XY_STABLE processing set up. These needs to be done anytime during the on-sync period.
| [[#amos|AMOS Maintainer]]
+
| AMOS Maintainer
 
|-
 
|-
 
| 9.
 
| 9.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
|  
+
| style="text-align:center" | &#10003;
| Clone MDL-42929, MDL-42930 and MDL-42931, to be resolved ASAP.
+
| Verify, 24h after tagging, that https://moodle.org/dev/contributions.php has been updated with new versions. If not, file an urgent mdlsite issue, crons must be running!
| [[#integration|Integration Lead]]
+
| Integration Lead
 
|-
 
|-
 
| 10.
 
| 10.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| style="text-align:center" | &#10003;
+
|  
| Verify, 24h after tagging, that https://moodle.org/dev/ has been updated with new versions.
+
| For en and de Moodle Docs, update default redirects and enable email notifications.
| [[#integration|Integration Lead]]
+
| Moodle Docs Maintainer
 
|-
 
|-
 
| 11.
 
| 11.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
|  
 
|  
| Update Moodledocs default redirect and add version link to https://docs.moodle.org/overview/
+
| Go through all points listed under Day of release in [[New docs version process]].
| [[#docs|Moodle Docs Maintainer]]
+
| Community Manager
 
|-
 
|-
 
| 12.
 
| 12.
Line 443: Line 665:
 
|  
 
|  
 
|
 
|
* 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 "Full demo", "Code freeze" and "QA begins" dates for the next X.(Y+1) major release and put them in the [https://www.google.com/calendar/ical/moodle.com_p4c2oe7hsb77ltaro5qtihb5d4%40group.calendar.google.com/public/basic.ics Moodle development calendar]. They will be -7w, -5w and -4w before release date respectively.
* 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 the "Full demo", "Code freeze", "QA begins" and Release dates on the [[Roadmap]] page.
* Update upcoming dates on the [[Roadmap]] page.
+
* Add events to the HQ calendar for next Major release 6-months cycle according to [[Process#Sprints|the cycle plan]]: ~4 weeks planning and regression fixing, 2 sprints, 1 personal project week, 2 sprints, 1 personal project week, 1 sprint (which should lead up to code freeze).
| [[#dev|Development Manager]]
+
* Notify the Community Manager of new dates to be added to the moodle.org calendar.
 +
| Development Manager
 
|-
 
|-
 
| 13.
 
| 13.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 +
| style="text-align:center" |
 +
| Add calendar events in the [https://moodle.org/calendar moodle.org calendar] for coming Major and Minor releases up to the next Major release.
 +
| Community Manager
 +
|-
 +
| 14.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| Upgrade all moodle.org and moodle.net sites to latest release version.
+
| style="text-align:center" | &#10003;
| [[#sysadmin|System Administrator]]
+
| Update release schedule image on [[Releases#Version_support|Releases page]]
 +
| Development Manager
 
|}
 
|}
  
 
==1 week after==
 
==1 week after==
{| class="nicetable" style="width:100%"
+
{| class="table table-striped table-bordered"
 
|-
 
|-
! #
+
! style="width:20px" | #
! Major
+
! style="width:20px" | Major
! Minor
+
! style="width:20px" | Minor
 
! Task
 
! Task
 
! style="width:12%" | Responsibility
 
! style="width:12%" | Responsibility
Line 468: Line 697:
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| Publish the X.Y+ packages for download.moodle.org (should be automatic once weeklies are packaged).
 
| Publish the X.Y+ packages for download.moodle.org (should be automatic once weeklies are packaged).
| [[#integration|Integration Lead]]
+
 
 +
For major releases, within the on-sync period, master packages will be generated using the prerelease.sh script (--type on-sync). That guarantees XY_STABLE and master versions are kept the same. The last week, when leaving the on-sync period, master package will be generated normally (implicit --type weekly), so versions will diverge and dev can continue separately from that point.
 +
| Integration Lead
 
|-
 
|-
 
| 2.
 
| 2.
Line 474: Line 705:
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| Update the version.php in git to be X.Y.Z+ during the next weekly integration process
 
| Update the version.php in git to be X.Y.Z+ during the next weekly integration process
| [[#integration|Integration Lead]]
+
| Integration Lead
 
|-
 
|-
 
| 3.
 
| 3.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| Create a new release notes page for the next minor versions (using the [[Release notes template|release notes template]].)
+
| Create a new release notes page for the next minor versions (using the [[Release notes template|release notes template]].) Add note to top of relevant version page about security support.
| [[#dev|Development Manager]]
+
| Development Manager
 
|-
 
|-
 
| 4.
 
| 4.
Line 486: Line 717:
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| Add all security advisories to [http://moodle.org/security Security news] and [[:Category:Release notes|release notes]] with links to security advisories
 
| Add all security advisories to [http://moodle.org/security Security news] and [[:Category:Release notes|release notes]] with links to security advisories
| [[#dev|Development Manager]]
+
|| Security Officer
 
|-
 
|-
 
| 5.
 
| 5.
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
| Send a plain text email to the OSS mailing list: [mailto:oss-security@lists.openwall.com oss-security@lists.openwall.com]. An appropriate message when sending the issues is...  
+
| Notify about publications of CVE using form: https://cveform.mitre.org/
:<tt>The following security notifications have now been made public. Thanks to OSS members for their cooperation.</tt>
+
| Security Officer
...followed by the security notes.
+
|-
| [[#dev|Development Manager]]
+
| 6.
 +
|  style="text-align:center" | &#10003;
 +
|
 +
| Upgrade moodle.org and all other Moodle community sites (next sites first, then production)
 +
|
 +
|-
 +
| 7.
 +
|  style="text-align:center" | &#10003;
 +
|
 +
| - Create the next deprecation epic (for XY+1+2y) similar to MDL-65798 and add standard issues to it about: final deprecation of lib/deprecatedlib.php (like MDL-65799), removal of deprecated behat steps (like MDL-65800) and removal of strings (like MDL-65801).
 +
- Review [https://tracker.moodle.org/issues/?jql=text%20~%20%22Collect%20together%20deprecated%20and%20planned%20code%20changes%20for%20Moodle%22%20AND%20affectedVersion%20in%20(releasedVersions()%2C%20%22Future%20Dev%22)%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuekey%20%20DESC how previous deprecation epics are going] and share about them.
 +
| Integration Lead
 +
|}
 +
 
 +
==2 weeks after==
 +
{| class="table table-striped table-bordered"
 +
|-
 +
! style="width:20px" | #
 +
! style="width:20px" | Major
 +
! style="width:20px" | Minor
 +
! Task
 +
! style="width:12%" | Responsibility
 +
|-
 +
| 1.
 +
| style="text-align:center" | &#10003;
 +
|
 +
| Once the "On Sync" period ends:
 +
* Confirm that versions (XY_STABLE and master) diverged properly the last on-sync week. If not, proceed to it by manually bumping master version to currentdate @ integration.git.
 +
* The "[https://tracker.moodle.org/issues/?filter=13669 integration_held]" label will be removed from all issues awaiting integration, so they will be, automatically (see next point), be moved to current integration. Send a "unholding + rebase" message to all those issues.
 +
* The "[https://ci.moodle.org/view/Tracker/job/TR%20-%20Move%20awaiting%20issues%20to%20current%20integration/ Move awaiting issues to current integration]" and "[https://ci.moodle.org/view/Tracker/job/TR%20-%20Delay%20awaiting%20issues/ Delay awaiting issues]" jobs will be re-enabled in the public CI server.
 +
* The discussion about environmental requirements for next X.Y+1 major release (MDL-65809) will end and the issue will be resolved '''immediately'''. A new issue, about the requirements for next-next X.Y+2 major release will be created at the same time by cloning the previous one and dragging any non-resolved detail (due date = 3w after release).
 +
| Integration Lead
 +
|-
 +
| 2.
 +
| style="text-align:center" | &#10003;
 +
|
 +
| In https://github.com/moodlehq/moodle-behat-extension project:
 +
* For the new stable version:
 +
*# Create a MOODLE_XY_STABLE branch from master
 +
* For master:
 +
*# Add a 3.X(Y+1).0 tag for the new release in the master branch (first number is the major behat release, currently 3.x).
 +
*# Clone MDL-64409, implement, and send it to integration.
 +
| Testing Maintainer
 +
|-
 +
| 3.
 +
| style="text-align:center" | &#10003;
 +
|
 +
| Ensure [https://download.moodle.org/langpack/X.Y+1/ Language pack for master (X.Y+1)] is available and merge the pull request MR4 for stop skipping the language upgrade in  [https://github.com/moodlehq/moodle-ci-runner moodle-ci-runner] repository.
 +
| Testing Maintainer
 +
|-
 +
| 4.
 +
| style="text-align:center" | &#10003;
 +
|
 +
| Hold a release retrospective with the entire team.
 +
| Development Manager
 
|}
 
|}
  
 
==1 month after==
 
==1 month after==
{| class="nicetable" style="width:100%"
+
{| class="table table-striped table-bordered"
 
|-
 
|-
! #
+
! style="width:20px" | #
! Major
+
! style="width:20px" | Major
! Minor
+
! style="width:20px" | Minor
 
! Task
 
! Task
 
! style="width:12%" | Responsibility
 
! style="width:12%" | Responsibility
Line 509: Line 794:
 
| style="text-align:center" | &#10003;
 
| style="text-align:center" | &#10003;
 
|  
 
|  
| Publish the X.(Y+1)dev packages for download.moodle.org
+
| Remove, in CI servers, all the jobs and views corresponding to branches which support has ended completely. (there is a [https://ci.moodle.org/view/maintenance/job/MAINT%20-%20Remove%20all%20jobs%20from%20view/ maintenance job] to perform the operation).
| [[#integration|Integration Lead]]
+
| Integration Lead
 +
|-
 +
| 2.
 +
| style="text-align:center" | &#10003;
 +
|
 +
| Upgrade all the Moodle CI sites to recent major release by configuring the "Moodle CI Auto Upgrade" job in all them.
 +
| Integration Lead
 +
|-
 +
| 3.
 +
| style="text-align:center" | &#10003;
 +
|
 +
| Confirm that there isn't any remaining [https://tracker.moodle.org/issues/?filter=13669 integration_held] issue from latest release, proceeding to uhhold them immediately. Note that there may exist others "held" issues, unrelated with latest release. This process step does not affect them.
 +
| Integration Lead
 
|}
 
|}
  
 
==See also==
 
==See also==
  
* [[Major release process]] (deprecated)
+
* [[Deprecation|Deprecation process]]
* [[Release process]] (deprecated)
 
* [[Deprecation|Deprecation process]] (not deprecated)
 
  
 
[[Category:Processes|Release process]]
 
[[Category:Processes|Release process]]
 
[[Category:Release notes|Release process]]
 
[[Category:Release notes|Release process]]

Latest revision as of 07:57, 14 October 2019

8 weeks prior

# Major Minor Task Responsibility
1. Create an issue to review latest stable version of all third party libraries and add to sprint. The issue should refer to the list at Moodle libraries credits. The issue can be based on MDL-52393. Development Manager
2. Ensure we are running latest/good behat, phpunit and nodejs (npm) versions. Integration Team
3. Confirm external testers daily availability from -6w to release (internally with dev manager and then, externally, with contractors). Integration Team
4. - Move QA tests for new features in old release with automated tests from MDLQA-1 to MDLQA-5249.

- Remind devs:

  • To label issues qa_test_required when a new feature/improvement is landing without automated tests. Also add a comment advising exactly what should be covered in the QA test e.g. steps 6-10 in testing instructions.
  • The best possible lang strings land at first attempt. Given the proximity of the major release and to facilitate the work of translators and others... the sooner, the better, instead of relying on (late) en_fixes too much.

- Contact with external testing towards preparing the continuous integration period (-6w to +2w, right now) starting in just 2 weeks.

Testing Maintainer
5. - Create a "Must fix for X.Y" version in the Tracker and adjust the "TR - Set integration priority to one" and "TR - Move reopened out from current" jobs in all CI servers to point to it.

- Apply the following changes to filters and dashboards:

  • Edit the All "must fix" issues filter used both in the release dashboard and to detect wrong uses of must-fix issues. Note that, since 3.7, this filter is fully automated and does not need edition (uses regexp to catch all must fix versions).
  • Comment about its creation within HQ, to get people applying for it.
  • Verify that these filters (1, 2 and 3), used in the Release urgent dashboard, are working ok (they should be, automatically based in the filter edited in the previous point).
  • Rename Release urgent dashboard to point to incoming release (QA part of the dashboard will not work yet)
Integration Lead

7 weeks prior

# Major Minor Task Responsibility
1. Full demo of new code and sign-off for internal HQ projects. Decide which projects will be completed by the code freeze. Lead Developer
2. Check closed qa_test_required-labelled issues and create new QA tests as required. Testing Maintainer

6 weeks prior

# Major Minor Task Responsibility
1. The Continuous Integration period begins. Warn about it everywhere (telegram, exposed posts...).

Rolling (on demand, beta, rc... all them together with stable weeklies) happens often (Tuesday & Friday are the usual days). All the team is on integration 100% since this week and until the end of continuous.

Integration Lead
2. 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
3. Warn external developers about the impending code freeze in a post to the General developer forum. (example) Development Manager

5 weeks prior

# Major Minor Task Responsibility
1. Confirm the code freeze by replying to the previous warning in the General developer forum. Development manager
2. This week, once the integration server has ended with Monday's job moving issues to integration (after 11:00 UTC), the following jobs have to be disabled:

(issues will be manually picked for integration until the post-release "On Sync" period ends, usually 2 weeks after release.

Review all the new features and improvements so, everything "unrelated" with the release, is given the "integration_held" label. That means that will be ignored unless there is an unhold request process started on them.

Dev leaders promptly vote on held issues labelled with unhold_requested label and decide whether they can be allowed to break the freeze

Integration Lead
3. Prepare a fresh installation of the QA 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
4. Write documentation on new features in the dev docs, adding a link to it from the tracker issue, together with the label docs_required. The documentation will then be transferred to the new en version wiki when it is set up (3 weeks prior) and polished, with screenshots added. Developers, Development manager to remind
5. Begin reviewing new and changed English language strings ready for en_fix to be merged 2 weeks prior. English fixes lang pack maintainer

4 weeks prior

# Major Minor Task Responsibility
1. Start working on the release notes (template) of the upcoming version. Development Manager
2. Create issues for adding User tours for new features in the upcoming version. Review existing tours and remove very old ones Development Manager
3. Beta release (The Moodle release tool - mdlrelease - manages it): Release normal weeklies but with these changes in the master branch being considered all the time, until we are feature complete (can happen @ -4w - ideally - but also later):
  • 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)
  • Automatic: Confirm packages are available under download.moodle.org (and windows).
  • Once the beta is available create the "testing matrix for X.Y.0" and share it @ HQ & Dev. chat.
  • (Optionally) Announce Beta release in forums (ideally once packages are available).
Integration Lead
4. Clone MDL-66881 for the X.Y release, adding there all the debugging / PHP notices happening in the web server logs while running tests. Integration Lead
5. Release candidates release (The Moodle release tool - mdlrelease - manages it): At some points (between beta to final release) produce release candidates (Z = 1, 2, 3..), which are normal builds with the following changes:
  • 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)
  • Automatic: Confirm packages are available under download.moodle.org (and windows).
  • Upgrade all the Moodle CI sites to recent release candidate by configuring the "Moodle CI Auto Upgrade" job in all them.
Integration Lead
6. Add a new version in the Plugins Directory with the version's name and the beta release version build number (https://moodle.org/plugins/admin/softwareversions.php). Plugins Liaison
7. Push any plugins to the plugins database which were previously a part of core. Plugins Liaison
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. Community Manager
9. Create new QA test cycle and post in development forum about QA testing. Testing Maintainer
10. Invite community volunteers to start QA testing. Community Manager
11. Modify Current QA cycle filter to link to the new QA test cycle Testing Maintainer
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 and credentials_required and external_skipped. 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. Community Manager
4. Go through all points listed under 3 weeks prior in New docs version process. Community Manager
5. Review issues with labelled with dev_docs_required, prompting assigned developers to create/update this documentation and remove this label when relevant docs are updated. Development Manager
6. Verify how everything is going and, before the end of the week, decide (dev leaders & integrators) if there are real reasons for delaying any release. Proceed to communicate any delay ASAP to both developers & partners. Don't forget to update calendars and tracker releases with the new dates. Development Manager

2 weeks prior

# Major Minor Task Responsibility
1.

Check the number of open QA tests. Depending on the amount of work involved, encourage HQ developers to assist from the start of the week or later in the week in order to achieve the target of 100% pass rate by the end of the week.

Development Manager
2.

Create MDLSITE issue to ensure all prototype.moodle.net sites which are no longer relevant (part of release) are removed from prototype.moodle.net

Development Manager
3. Merge fixes from en_fix pack and then integrate them. AMOS Maintainer
4. Give Partners complete brandable Marketing pack for release including list and description of major new features. Marketing Manager
5. Label (ui_change) in the Tracker all pending issues having noticeable UI modifications and track them in the "Late landing UI changes" sheet, in order to have all the associated docs, screenshots, videos under control. The Integration and Documentation people will try to keep the sheet updated until release. Integration Lead

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, verifying that there aren't open issues using that version. Integration Lead
3. Clone MDL-65571 and bump all versions, requires and dependencies along all plugins in codebase to planned release dates. Integration Lead
4. Post a "Heads-up" message on the General Developer forum. Development Manager
5. Post a "Heads-up" message on the Partners forum. Security Officer
6. Post a "Heads-up" message on Twitter and other outlets. Marketing Officer
7. Identify security issues that need to be integrated using the security issues under integration filter (includes held, being integrated and ready issues).
  • 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. Note that the --weekly releases to be performed this week are 100% normal and cover the standard (supported) branches. security branches will come as part of the release process later in the week.
Integration Lead
8. Collect security issues into a clone of the last advisory in the list to prepare for release of Security Advisories.
  • Determine which security issues will be integrated.
  • Request CVE Identifiers by emailing issue descriptions to secalert@redhat.com 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 (since 2015 we request identifiers from redhat and not from distros).
  • Post security issues as a reply to the "Heads-up" message on the Partners forum.
Security Officer
9. Review and complete the release notes, making sure that issues have easily understandable summaries. Aim to have the release notes mostly complete on the Wednesday before release, and fully complete on the Friday, to give translators time to translate them.
  • Ensure all issues labelled with "ui_change", "api_change" and "release_notes" are listed as UI changes, functional changed and fixes/improvements respectively in the release notes.
Development Manager
10. Check on the "Must fix for X.Y version". Filter out unrealistic issues. Development Manager
11. Upgrade moodle.org to beta release
12. Upgrade moodle.org and all other Moodle community sites (next sites first, then production) - Friday before release if not before
13. Prepare pull requests for CI Repositories: Testing Maintainer
14. Go through all points listed under 1 week prior in New docs version process. Community Manager

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. Check list:
  • Make sure there are no real blockers introduced in the last weekly (install / upgrade ...).
  • Confirm that the latest en_fix changeshave been generated and integrated.
  • Verify that all security issues have been integrated and there are not leftovers in the security area (but for delayed majors, where some security issues may have been introduced along the delay and they will be postponed to next minors).
Integration Lead
2. Verify all unit tests and integration tests have passed (check all current CI servers in use). Integration Lead
3. Verify QA tests have passed. Integration Lead
4. Timing prerequisites (don't continue with the process if not within the time window!):
  1. Latest weeklies before the minor/major releases must be done (moodle-package-extract-and-postprocess email should confirm this has happened around 09:00 Australia/Perth).
  2. Minor and major releases can be packaged at any time within the 96 hours before the automatic releasing time (Monday 09:00 Australia/Perth). And always, at very least, 4 hours before then (to allow the server to prepare all the stuff).

(in practice, this means that the packaging of minor/major releases must be done, assuming that weeklies were rolled normally on Thursday, between Friday 09:00 and Monday 05:00 (Australia/Perth times). Breaking any of these rules will require manual operation in the server, forcing repackaging and releasing.

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. Pay attention to the complete output of the process: permissions, svg, travis changes (only for majors)... Triple verify all changes are correct! (can use the --show option to inspect them). Follow the on-screen instructions.
  • Push changes to integration.git (but tags).

For major releases only:

  • Run the prerelease.sh script (--type back-to-dev) to move master to next X.Y+1 development version/branch.
  • 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 #12 below).
  • Configure "mdlrelease" (config.sh) to know about the new MOODLE_XY stable branch.
  • Update the old CI server(s) by cloning all the "master" jobs to a new "MXY" view (trick: do it down-top, way easier). Adjust "master" compare DB jobs to check for upgrade from MOODLE_XY_STABLE. Don't forget to re-chain the jobs properly. Run them.
  • Update the new CI infrastructure:
    • MR1: Merge pull request for new version in CI Jobs Repository
    • MR2: Merge pull request for symlink in moodle-ci-runner repository.
    • MR3: Merge pull request for skipping the language upgrade in moodle-ci-runner repository.
    • Clone all the "B - master" jobs to a new "B - XY" view (there is a maintenance job to perform the operation).

Both with minors and majors, continue with the "mdlrelease" steps:

  • Once CI servers have ended and all jobs have passed, push tags and run the release.sh script to apply the changes to moodle.git.
  • If needed configure "mdlrelease" (config.sh) to get rid of any unsupported version and adjust stable and security branches. Make a pull request with the changes.
  • Don't forget the "After the release" tasks.
Integration Lead
5. Post a "git repos updated & tagged" message on the Partner forum Integration Lead
6. In the performance comparison repository, set the new release commit hash as $basecommit in the master branch and create a new MOODLE_XY_STABLE branch from it. (example). Testing Maintainer
7. Wait for the automated (every 2 hours) moodle-package to finish building for all versions. Verify the process has ended successfully (email). Integration Lead
8.
  • Create new windows packager script (cloning the current master one and configuring it).
  • Create new windows_wpiXY dir by cloning the previous one (HEAD based), configuring build-latest-XY.sh.
  • Edit the stats.php script (in the moodle-local_downloadmoodleorg repository), adding the new branch to the versions. Push it. Next time the plugin is deployed (normally 1 week after release, aprox.) the stats will start showing the new branch statistics.
Integration Lead
9. In the Tracker...
  • Visit the versions page and make the release, bumping all remaining open bugs to the next point release. If there is not next (end of support), clean that version from all the issues having it as "Fix for". This must be done both for the Moodle Project and the Plugins project. Archive any version > 6 months old, verifying that there aren't open issues using that version.
  • Remove from all screens the custom fields belonging to 100% unsupported branches.

For major releases only:

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. Re-index Tracker.
  • In the CI server edit the "Bulk precheck issues" and "Pre-launch DEV jobs (awaiting_integration)" jobs to make them meet the new "Pull X.Y Branch" field created.
  • Edit the "Tracker - CI - Check marked as integrated" jobs in both servers (1, 2) to configure the master version to point to XY+1.
Integration Lead
11. In the Tracker...

For major releases only:

  • Create the new "X.Y regressions" version to be applied to every issue found to be a recent problem introduced by the major release. These issues should get priority after release.
  • Adjust the filters Latest regressions and High Priority Bugs.

For all releases:

  • Verify how the "X.Y regressions" versions are going and ping Development Managers about. Package and archive them once empty.
Integration Lead
12. Clone MDL-65643 and MDL-65644, to be resolved ASAP. Integration Lead
13.
  • Create the new MOODLE_XY_STABLE and lastbased-MOODLE_XY_STABLE branches in the security repo (branching from the just created upstream MOODLE_XY_STABLE branch).
  • Cherry pick any security commit present in the security repository's master branch to the new MOODLE_XY_STABLE branch (note that normally there should not be any, see point #1 check list above).
  • Verify the new security jobs exist for the new branch and check it's working in all servers, keeping only enabled the public one.
Integration Lead
14. Protect the MOODLE_XY_STABLE branches in github interface to prevent non-FF accidents ( MDLSITE-4183 ) Integration Lead
15. The "integration_held" label will be removed only from bug issues awaiting integration; they correspond to last-week bugs that were held because of them being unrelated with the release. Now they can be processed, under on-sync rules. Standard message will be used to explain the un-hold. 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. Verify release status, download pages and windows packages. Integration Lead
3. If needed, modify the downloads cfg script (serverscripts) to decide about branches status, master visibility and windows availability. Push changes, will be autodeployed in a few minutes. Integration Lead
4. Add/update the release date, build number and link on the Releases page and date in new version pages. Integration Lead
5. Notify all registered sys admins, including security notes with CVE identifiers, using the mailing list server. Security Officer
6. Post about the Major release on the moodle.org News forum Lead Developer
7. Post about minor releases on the moodle.org News forum Development Manager
8. New "X.Y+1dev" branch to be created in AMOS, to have master changes performed there. New install_XY_STABLE processing set up. These needs to be done anytime during the on-sync period. AMOS Maintainer
9. Verify, 24h after tagging, that https://moodle.org/dev/contributions.php 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 and enable email notifications. Moodle Docs Maintainer
11. Go through all points listed under Day of release in New docs version process. Community Manager
12.
  • Decide the "Full demo", "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 -7w, -5w and -4w before release date respectively.
  • Update the "Full demo", "Code freeze", "QA begins" and Release dates on the Roadmap page.
  • Add events to the HQ calendar for next Major release 6-months cycle according to the cycle plan: ~4 weeks planning and regression fixing, 2 sprints, 1 personal project week, 2 sprints, 1 personal project week, 1 sprint (which should lead up to code freeze).
  • Notify the Community Manager of new dates to be added to the moodle.org calendar.
Development Manager
13. Add calendar events in the moodle.org calendar for coming Major and Minor releases up to the next Major release. Community Manager
14. Update release schedule image on Releases page Development Manager

1 week after

# Major Minor Task Responsibility
1. Publish the X.Y+ packages for download.moodle.org (should be automatic once weeklies are packaged).

For major releases, within the on-sync period, master packages will be generated using the prerelease.sh script (--type on-sync). That guarantees XY_STABLE and master versions are kept the same. The last week, when leaving the on-sync period, master package will be generated normally (implicit --type weekly), so versions will diverge and dev can continue separately from that point.

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.) Add note to top of relevant version page about security support. Development Manager
4. Add all security advisories to Security news and release notes with links to security advisories Security Officer
5. Notify about publications of CVE using form: https://cveform.mitre.org/ Security Officer
6. Upgrade moodle.org and all other Moodle community sites (next sites first, then production)
7. - Create the next deprecation epic (for XY+1+2y) similar to MDL-65798 and add standard issues to it about: final deprecation of lib/deprecatedlib.php (like MDL-65799), removal of deprecated behat steps (like MDL-65800) and removal of strings (like MDL-65801).

- Review how previous deprecation epics are going and share about them.

Integration Lead

2 weeks after

# Major Minor Task Responsibility
1. Once the "On Sync" period ends:
  • Confirm that versions (XY_STABLE and master) diverged properly the last on-sync week. If not, proceed to it by manually bumping master version to currentdate @ integration.git.
  • The "integration_held" label will be removed from all issues awaiting integration, so they will be, automatically (see next point), be moved to current integration. Send a "unholding + rebase" message to all those issues.
  • The "Move awaiting issues to current integration" and "Delay awaiting issues" jobs will be re-enabled in the public CI server.
  • The discussion about environmental requirements for next X.Y+1 major release (MDL-65809) will end and the issue will be resolved immediately. A new issue, about the requirements for next-next X.Y+2 major release will be created at the same time by cloning the previous one and dragging any non-resolved detail (due date = 3w after release).
Integration Lead
2. In https://github.com/moodlehq/moodle-behat-extension project:
  • For the new stable version:
    1. Create a MOODLE_XY_STABLE branch from master
  • For master:
    1. Add a 3.X(Y+1).0 tag for the new release in the master branch (first number is the major behat release, currently 3.x).
    2. Clone MDL-64409, implement, and send it to integration.
Testing Maintainer
3. Ensure Language pack for master (X.Y+1) is available and merge the pull request MR4 for stop skipping the language upgrade in moodle-ci-runner repository. Testing Maintainer
4. Hold a release retrospective with the entire team. Development Manager

1 month after

# Major Minor Task Responsibility
1. Remove, in CI servers, all the jobs and views corresponding to branches which support has ended completely. (there is a maintenance job to perform the operation). Integration Lead
2. Upgrade all the Moodle CI sites to recent major release by configuring the "Moodle CI Auto Upgrade" job in all them. Integration Lead
3. Confirm that there isn't any remaining integration_held issue from latest release, proceeding to uhhold them immediately. Note that there may exist others "held" issues, unrelated with latest release. This process step does not affect them. Integration Lead

See also