Major release process: Difference between revisions
From MoodleDocs
m (→Beta release) |
|||
Line 14: | Line 14: | ||
# Announce it? | # Announce it? | ||
# [[Weekly Code Review|Test / QA]], etc | # [[Weekly Code Review|Test / QA]], etc | ||
# Review all the issues with labels "[http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=labels+%3D+docs_required docs_required]" and "[http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=labels+%3D+qa_test_required qa_test_required]", cleaning | # Review all the issues with labels "[http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=labels+%3D+docs_required 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). | # 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: | # At some points we can be producing release candidates (Z = 1, 2, 3..), they are normal builds but with: |
Revision as of 14:02, 15 November 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:
- 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.
- 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).
- Announce it?
- Test / QA, etc
- Review all the issues with labels "docs_required" and "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).
Stable release
Release day
- Verify all unit tests, QAs and integration tests pass!
- Run the mdlrelease process (with the special steps for Major releases).
- 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.
- Update the Latest Release block on Moodle.org news
- Post about the release in the moodle.org news
Post release
- Clone MDL-28169 and MDL-28170, to be resolved ASAP.
- Clone MDL-29705 for next minor release X.Y+1 handling of security issues & security advisories.
- 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
- 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 one template for that)
- Prepare, spam and publish in Docs the security stuff (Security news and release notes with links to security advisories)
One month after
- Publish the X.(Y+1)dev packages @ download.moodle.org