Note:

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

Major release process

From MoodleDocs

Note: This page is a work-in-progress. Feedback and suggested improvements are welcome. Please join the discussion on moodle.org or use the page comments.


This page describes the standard procedures for making a major release e.g. Moodle 2.0.

Beta release

One month and a half before

  1. Create the next "X.Y+1 (next dev)" version in the Tracker (MDL and CONTRIB), so people can move delayed stuff to next major release if needed.

Freeze Day

  1. Freeze stable development and post in the General developer forum to inform everyone of the freeze. (example)

One month before

  1. Review and complete the 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.
  2. Release normal weeklies but with these changes in the master branch:
    • version.php: Move to $maturity = MATURITY_BETA and $release = 'X.Ybeta (Build:xxxxxxxx)'
    • tag git repo with: "vX.Y.0-beta" (and MOODLE_XY_BETA as description and CVS tag)
    • 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).
  3. Optionally: Announce it in forums (ideally once packages are available).
  4. Test / QA, etc
  5. Review all the issues with labels "docs_required", "dev_docs_required" and "qa_test_required", cleaning while done.
  6. During the QA/Test weeks continuous integration will happen, releasing STABLE weeklies normally but master ones as often as possible (on demand).
  7. 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

  1. Clone as many filters as needed in the Tracker, modifying them to point to the new, upcoming, branch (keeping same perms, title...).
  2. Create new minor version X.Y.1 in the Tracker.
  3. Clone MDL-39434 and bump all versions, requires and dependencies along all plugins in codebase to current date.
  4. Post an "advanced release" message on the Partner forum
  5. Ask the AMOS maintainer to merge fixes from en_fix pack and then integrate them.
  6. In https://github.com/moodlehq/moodle-behat-extension project, create a 1.NN.0 tag for the new release (where NN = 25 in Moodle 2.5)

Stable release

Release day

  1. Verify all unit tests, QAs and integration tests pass!
  2. Run the mdlrelease process (with the special steps for Major releases).
  3. 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).
  4. In the download server:
    • NOTE: All these steps are being reworked in the switch from cvs to git. Will be updated once the new process is 100% ready.
    • Create the moodle/stableXY and download/stableXY (empty) dirs
    • cvs -q update -dPr MOODLE_XY_STABLE the moodle/stableXY dir
    • Edit /opt/bin/moodle-cvsupdate and /opt/bin/moodle with new version
    • Create and run moodle-makenightlystableXY (add it where necessary - crons and friends)
    • Go to download/stableXY
    • Copy current daily as release package:
      1. cp moodle-latest-XY.zip moodle-X.Y.zip
      2. cp moodle-latest-XY.tgz moodle-X.Y.tgz
    • Edit download index.php page with new release info and links
    • Create new windows packager script (cloning the current master one and configuring it) and add it to moodle-makewindowspackages)
    • Run moodle-makewindowspackages so all the windows packages will be rebuilt
    • Edit download windows/index.php page with new release info (always keeping the "+")
    • 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 and executing it.
    • Edit /opt/bin/moodle-makewindows_wpipackages to switch to the new version.
    • Edit stats script to include the new branch into the versions.
    • Run SF's mirror script
  5. Update release date, number and link on Releases page
  6. In Tracker:
    • "Release" the current version (with current date) and push any remaining open issues to the next point release (eg 2.2 -> 2.2.1) for developers to deal with there. This must be done both for the Moodle Project and the Non-core contributed modules project.
    • Rename the "X.Y+1 (next dev)" version to "X.Y+1".
    • 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.
  7. (deprecated) Update the Latest Release block on Moodle.org news
  8. Update the release version build number in the Plugins Directory with actual release date (https://moodle.org/plugins/admin/softwareversions.php).
  9. Post about the release in the moodle.org news
  10. AMOS needs new "X.Y+1dev" branch to be created, to have master changes performed there. Notify it to the responsible.

Post release

  1. Clone MDL-37032 and MDL-37033, to be resolved ASAP.
  2. Clone MDL-37058 for next minor release X.Y.1 handling of security issues & security advisories.
  3. Integrate MDL-38532 into the released version, MDL-39489 into the next version (master branch) and clone both issues for the next release
  4. Deprecated since 2.4 (CVS is death) Create the MOODLE_XY_STABLE branch for the whole 'contrib' subdir in CVS.
  5. 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.
  6. 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).
  7. (For convenience) force update of moodle.org/dev/
  8. Update Moodledocs default redirect and add version link to https://docs.moodle.org/overview/

One week after

  1. Publish the X.Y+ packages @ download.moodle.org
  2. Create a new release notes page for the next version X.Y.1 (here you can find one template for that)
  3. Prepare, spam and publish in Docs the security stuff (Security news and release notes with links to security advisories)

One month after

  1. Publish the X.(Y+1)dev packages @ download.moodle.org
  2. 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

Retrieved from "https://docs.moodle.org/dev/index.php?title=Major_release_process&oldid=39497"
Powered by MediaWiki