Major release process: Difference between revisions
From MoodleDocs
m (→Release day) |
|||
Line 75: | Line 75: | ||
# (For convenience) force update of moodle.org/dev/ | # (For convenience) force update of moodle.org/dev/ | ||
# Update Moodledocs default redirect and add version link to https://docs.moodle.org/overview/ | # Update Moodledocs default redirect and add version link to https://docs.moodle.org/overview/ | ||
==== One week after ==== | ==== One week after ==== |
Revision as of 01:13, 4 December 2012
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
- 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.
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 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).
- Announce it in forums (ideally once packages are available).
- Test / QA, etc
- Review all the issues with labels "docs_required", "dev_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).
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.
- Clone MDL-33794 and bump all versions, requires and dependencies along all plugins in codebase to current date.
- Post an "advanced release" message on the Partner forum
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 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:
- cp moodle-latest-XY.zip moodle-X.Y.zip
- 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
- Update release date, number and link on Releases page
- 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.
- (deprecated) Update the Latest Release block on Moodle.org news
- Post about the release in the moodle.org news
Post release
- Clone MDL-34096 and MDL-34097, to be resolved ASAP.
- Clone MDL-34098 for next minor release X.Y.1 handling of security issues & security advisories.
- 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, 1 month 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 one template for that)
- Prepare, spam and publish in Docs the security stuff (Security news and release notes with links to security advisories)
- (@todo: integrate the advisories under the CVE advisories standard).
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.