Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Major release process: Difference between revisions

From MoodleDocs
m (Linking to new page (combined is not the target anymore))
 
(17 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Template:Work_in_progress}}
#REDIRECT [[Release process]]
 
This page describes the standard procedures for making a major release e.g. Moodle 2.0.
 
==Beta release==
 
===One month and a half before===
 
# 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.
 
===Freeze Day===
 
# 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])
 
===One month before===
 
# Review and complete the [[Releases|release notes]] and upgrading notes of the upcoming version.
#* Ensure all issues labelled with "ui_change" or "api_change" are listed as functional or API changes respectively in the release notes.
# Release normal weeklies but with these changes in the master branch:
#* version.php: Move to $maturity = MATURITY_BETA and $release  = 'X.Ybeta (Build:xxxxxxxx)'
#* tag git repo with: "vX.Y.0-beta" (and MOODLE_XY_BETA as description and CVS tag)
#* Make packages available under download.moodle.org (and windows). Promote master up in the download page and adjust info for it.
#* 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).
# Optionally: Announce it in forums (ideally once packages are available).
# [[Weekly Code Review|Test]] / [[QA testing|QA]], etc
# Review all the issues with labels "[http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=labels+%3D+docs_required docs_required]", "[http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=labels+%3D+dev_docs_required dev_docs_required]" and "[http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=labels+%3D+qa_test_required qa_test_required]", cleaning while done.
# During the QA/Test weeks continuous integration will happen, releasing STABLE weeklies normally but master ones as often as possible (on demand).
# At some points we can be producing release candidates (Z = 1, 2, 3..), they are normal builds but with:
#* version.php: Move to $maturity = MATURITY_RC and $release  = 'X.YrcZ (Build:xxxxxxxx)'
#* tag git repo with: "vX.Y.0-rcZ"  (and MOODLE_XY_RCZ as description and CVS tag)
#* Make packages available under download.moodle.org (and windows).
 
===One week before===
# Clone as many filters as needed in the Tracker, modifying them to point to the new, upcoming, branch (keeping same perms, title...).
# Create new minor version X.Y.1 in the Tracker (MDL and CONTRIB).
# Clone MDL-39434 and bump all versions, requires and dependencies along all plugins in codebase to current date.
# Post an "advanced release" message on the [http://partners.moodle.com/mod/forum/view.php?id=2 Partner forum]
# Ask the AMOS maintainer to merge fixes from en_fix pack and then integrate them.
# In https://github.com/moodlehq/moodle-behat-extension project:
#* For the new stable version
#*# Create a MOODLE_XY_STABLE branch from master
#*# Hardcode upstream projects versions in moodle-behat-extension/composer.json according to the latest pulled versions when installing/updating the dependencies to avoid upstream changes breaking stable branches tests
#*# Add a 1.XY.n tag to point to this new branch last commit
#* For master
#*# Add a 1.X(Y+1).0 tag for the new release in the master branch
# 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.
 
===During week prior to release===
 
# 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.
 
==Stable release==
 
=== Packaging day ===
 
# Make sure there are not real blockers introduced by last weekly (install / upgrade ...)
# Verify all unit tests, QAs and integration tests pass!
# Run the [https://github.com/moodlehq/mdlrelease/blob/master/weeklybuild.txt mdlrelease] process (with the [ https://github.com/moodlehq/mdlrelease/blob/master/releasemajor.txt special steps] for Major releases),  that will do, for a major release:
#* Edit version.php, update release and version to new release and commit in the integration repository
#* Tag the integration repository with a tag name vX.Y.0 using "MOODLE_XY" as a tag message
#* Create the new MOODLE_XY_STABLE branch
#* Move master to next X.Y+1 version
#* push change to main git repo, github and Gitorious
# Update the integration server by cloning all the "master" jobs to a new "MXY" view. Adjust "master" compare DB jobs to check for upgrade from MOODLE_XY_STABLE (note, this is part of the mdlrelease process above).
# 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 "+")
#* Create new windows packager script (cloning the current master one and configuring it)
#* Copy the xampp_version_head.php file to xampp_version_XY.php
#* Create new windows_wpiXY dir by cloning the previous one (HEAD based), configuring build-latest-XY.sh
#* Edit stats script to include the new branch into the versions.
# 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 [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.
#* 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. Hide from all screens the corresponding X.Y-3 custom fields.
# 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 ===
 
# 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 [http://moodle.org/news/ moodle.org news]
# (deprecated) Update the Latest Release block on [http://moodle.org/news/ Moodle.org news]
# AMOS needs new "X.Y+1dev" branch to be created, to have master changes performed there. Notify it to the responsible.
# Update the release version build number in the Plugins Directory with actual release date (https://moodle.org/plugins/admin/softwareversions.php).
 
=== Post release ===
 
# Clone MDL-37032 and MDL-37033, to be resolved ASAP.
# Clone MDL-37058 for next minor release X.Y.1 handling of security issues & security advisories.
# Integrate MDL-38532 into the released version, MDL-39489 into the next version (master branch) and clone both issues for the next release
# Deprecated since 2.4 (CVS is death) Create the MOODLE_XY_STABLE branch for the whole 'contrib' subdir in CVS.
# Deprecated since 2.2 (we don't package anything anymore from contrib): Edit /opt/bin/moodle-cvsupdate and /opt/bin/moodle with new version contrib packages.
# Prepare/verify and publish the calendar for next Major release (basis are, for 6-months periods: 1 month for furious bugfixing release, 1 month for planning, 3 months for developments, 6 weeks for QA, candidates/betas/release).
# (For convenience) force update of moodle.org/dev/
# Update Moodledocs default redirect and add version link to https://docs.moodle.org/overview/
 
==== One week after ====
# Publish the X.Y+ packages @ download.moodle.org
# Create a new release notes page for the next version X.Y.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
# 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.
 
==== One month after ====
# Publish the X.(Y+1)dev packages @ download.moodle.org
# Decide the "code freeze" and "qa begins" days for next X.(Y+1) major release and put them in the moodle.development calendar. Unless exception they will be -6w and -5w before release date.
 
==See also==
 
* [[Release process]]
* [[Deprecation]]
 
[[Category:Processes|Release process]]
[[Category:Release notes|Release process]]

Latest revision as of 11:23, 30 January 2015

Redirect to: