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 before

  1. Freeze stable development and post in the General developer forum to inform everyone of the freeze
  2. Review and complete the release notes and upgrading notes of the upcoming version.
  3. 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).
  4. Announce it in forums (ideally once packages are available).
  5. Test / QA, etc
  6. Review all the issues with labels "docs_required" and "qa_test_required", cleaning while done.
  7. During the QA/Test weeks continuous integration will happen, releasing STABLE weeklies normally but master ones as often as possible (on demand).
  8. 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.

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. In the download server:
    • Create the stableXY and download/stableXY dirs
    • cvs -q update -dP all code on download server
    • 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 where necessary - cron scripts and friends)
    • Run moodle-makewindowspackages so all the windows packages will be rebuilt
    • Edit download windows/index.php page with new release info (always keeping the "+")
    • Run SF's mirror script
  4. Update links on Releases page
  5. 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.
  6. Update the Latest Release block on Moodle.org news
  7. Post about the release in the moodle.org news

Post release

  1. Clone MDL-30604 and MDL-30605, to be resolved ASAP.
  2. Clone MDL-29705 for next minor release X.Y.1 handling of security issues & security advisories.
  3. Prepare 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, 1 month for QA, candidates/betas/release).

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

See also