Archive release process: Difference between revisions

Latest revision as of 07:13, 26 May 2022

Warning: This page is no longer in use. The information contained on the page should NOT be seen as relevant or reliable.

Please see the Release process page.

For a stable release on an existing branch XY with point value Z (eg. X.Y.Z)

One week before

Notify Moodle developers and Moodle Partners about the upcoming release
- Ask the AMOS maintainer to merge fixes from en_fix pack and then integrate them.
Identify security issues that need to be integrated.
- 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.
- Collect security issues into a clone of MDL-39530 to prepare for release of Security Advisories.
Freeze stable development and post in the General developer forum to inform everyone of the freeze
Review and complete the release notes of the upcoming version using the template
- Ensure all issues labelled with "ui_change" or "api_change" are listed as functional or API changes respectively in the release notes.
Begin preparing the security advisories to be sent on release day.
Test / QA etc.

During the week prior release

Normal integration / testing / upstream / weekly cycle. It will constitute, somehow, the "release candidate" to be packaged and released.
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.
Create the next X.Y.Z+1 versions in the Tracker (both for the Moodle Project and the Non-core contributed modules project).

Packaging day

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).

Make sure there are not real blockers introduced by last weekly (install / upgrade ...)
Make sure all the Unit tests pass!
Run the mdlrelease process, that will do, for a release:
- Edit version.php, update release and version to new point release and commit in the integration repository
- Tag the integration repository with a tag name vX.Y.Z using "MOODLE_XYZ" as a tag message
- push change to main git repo, github and Gitorious
Wait the automated moodle-package to finish building all the versions. Verify the process has ended ok (email).
In 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 "+")
In the Tracker:
- Visit releases page on tracker 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 Non-core contributed modules project. Archive every released version > 6mo ago.
- Hide from all screens the custom fields belonging to 100% unsupported branches.
Add/update the release date, build number and link on the Releases page.
Post a "git repos updated & tagged" done message on the Partner forum

Release day

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).
Replace the download/index.php page with its updated counterpart.
Replace the download/windows/index.php page with its updated counterpart.
Notify all registered sys admins, including security notes with CVE identifiers.
Post about the release in the moodle.org news
(deprecated) Update the Latest Release block on Moodle.org news

One week after release day

Update the version.php in git to be X.Y.Z+ during the next weekly integration process
Create a new release notes page for the next version X.Y.(Z+1) (here you can find one template for that)
Add all security advisories to Security news and release notes with links to security advisories
Send a plain text email to the following email 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.

@@ Line 1: / Line 1: @@
-This page describes the standard procedures for making Moodle releases.
+{{Template:WillNotMigrate}}
+{{obsolete}}
+Please see the [[Release process|Release process]] page.
 ==For a stable release on an existing branch XY with point value Z (eg. X.Y.Z)==
@@ Line 5: / Line 9: @@
 ===One week before===
 # Notify Moodle developers and Moodle Partners about the upcoming release
+#* Ask the AMOS maintainer to merge fixes from en_fix pack and then integrate them.
 # Identify security issues that need to be integrated.
 #* 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.
+#* Collect security issues into a clone of MDL-39530 to prepare for release of Security Advisories.
 # 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
 # Review and complete the [[:Category:Release notes|release notes]] of the upcoming version using the [[Release notes template|template]]
@@ Line 18: / Line 24: @@
 # Determine which security issues will be integrated.
 #* 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 '''[vs]'''. 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.
-# Create the next X.Y.Z+1 versions in the Tracker (both MDL and CONTRIB).
+# Create the next X.Y.Z+1 versions in the Tracker (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 Non-core contributed modules project]).
 ===Packaging day===
@@ Line 25: / Line 31: @@
 # Make sure there are not real blockers introduced by last weekly (install / upgrade ...)
 # Make sure all the Unit tests pass!
-# Run the [https://github.com/skodak/mdlrelease/blob/master/weeklybuild.txt mdlrelease] process, that will do, for a release:
+# Run the [https://github.com/moodlehq/mdlrelease/blob/master/weeklybuild.txt mdlrelease] process, that will do, for a release:
 #* Edit version.php, update release and version to new point release and commit in the integration repository
 #* Tag the integration repository with a tag name vX.Y.Z using "MOODLE_XYZ" as a tag message
 #* push change to main git repo, github and Gitorious
-# Duplicate the download/index.php page and amend it with new release info and links
+# Wait the automated moodle-package to finish building all the versions. Verify the process has ended ok (email).
-# Duplicate the download/windows/index.php page and amend it with new release info (always keeping the "+")
+# In the download server:
-# Visit releases page on tracker 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 Non-core contributed modules project]. Archive every released version > 6mo ago.
+#* Duplicate the download/index.php page and amend it with new release info and links
-# Add the release date, build number and link to [[Releases]]
+#* Duplicate the download/windows/index.php page and amend it with new release info (always keeping the "+")
-# Clone MDL-36495, MDL-36496, MDL-36497 for next minor release X.Y.(Z+1) handling of security issues & security advisories.
+# In the Tracker:
-# Post an "advanced release" message on the [http://partners.moodle.com/mod/forum/view.php?id=2 Partner forum]
+#* Visit releases page on tracker 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 Non-core contributed modules project]. Archive every released version > 6mo ago.
+#* Hide from all screens the custom fields belonging to 100% unsupported branches.
+# Add/update the release date, build number and link on the [[Releases]] page.
+# Post a "git repos updated & tagged" done message on the [http://partners.moodle.com/mod/forum/view.php?id=2 Partner forum]
 ===Release day===
-# Verify packaging has happened.
+# 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).
-# Notify all registered sys admins, including security notes with CVE idenifiers.
+# Replace the download/index.php page with its updated counterpart.
+# Replace the download/windows/index.php page with its updated counterpart.
+# Notify all registered sys admins, including security notes with CVE identifiers.
+# Post about the release in the [http://moodle.org/news/ moodle.org news]
 # (deprecated) Update the Latest Release block on [http://moodle.org/news/ Moodle.org news]
-# Post about the release in the [http://moodle.org/news/ moodle.org news]
 ===One week after release day===
 # Update the version.php in git to be X.Y.Z+ during the next weekly integration process
+# Create a new release notes page for the next version X.Y.(Z+1) (here you can find [[Release notes template|one template for that]])
 # Add all security advisories to [http://moodle.org/security Security news] and [[:Category:Release notes|release notes]] with links to security advisories
-#* (@todo: [http://feeding.cloud.geek.nz/2009/03/handling-security-bugs-in-your-free.html integrate the advisories] under the [http://cve.mitre.org/ CVE advisories] standard).
-# Create a new release notes page for the next version X.Y.(Z+1) (here you can find [[Release notes template|one template for that]])
 # Send a plain text email to the following email list: [mailto:oss-security@lists.openwall.com oss-security@lists.openwall.com] An appropriate message when sending the issues is... <tt>The following security notifications have now been made public. Thanks to OSS members for their cooperation.</tt> ...followed by the security notes.
@@ Line 55: / Line 65: @@
 * [[Major release process]]
 * [[Deprecation]]
-* MDLSITE-699: How to repackage one weekly at any moment (a.k.a. "emergency weekly").
 [[Category:Processes|Release process]]
 [[Category:Release notes|Release process]]

Documentation