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
Line 10: Line 10:
# [[Weekly Code Review|Test / QA]] etc
# [[Weekly Code Review|Test / QA]] etc


==Stable release==


Release day:
Release day:

Revision as of 00:59, 13 July 2011

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 of the upcoming version.
  3. Test / QA etc


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 Tracker, "release" the current version (with current date) and push any remaining open issues to the next point release (eg 2.1 -> 2.1.1) for developers to deal with there.
  4. Post about the release in the moodle.org news

Post release:

  1. Clone MDL-28169 and MDL-28170, to be resolved ASAP.
  2. Clone MDL-28314 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).
  4. 1 week after release, publish the X.Y+ packages @ download.moodle.org
  5. 1 week after release, spam and publish in Docs the security stuff (Security news and release notes with links to security advisories)
  6. 1 month after release, when next dev starts to diverge, publish the X.(Y+1)dev packages @ download.moodle.org

See also