Archive release process: Difference between revisions
From MoodleDocs
| Line 28: | Line 28: | ||
# Edit download windows/index.php page with new release info (always keeping the "+") | # Edit download windows/index.php page with new release info (always keeping the "+") | ||
# Visit releases page on tracker and make the release, bumping all remaining open bugs to the next point release. This must be done both for the [http://tracker.moodle.org/secure/project/ViewProject.jspa?pid=10011 Moodle Project] and the [http://tracker.moodle.org/secure/project/ViewProject.jspa?pid=10033 Non-core contributed modules project]. | # Visit releases page on tracker and make the release, bumping all remaining open bugs to the next point release. This must be done both for the [http://tracker.moodle.org/secure/project/ViewProject.jspa?pid=10011 Moodle Project] and the [http://tracker.moodle.org/secure/project/ViewProject.jspa?pid=10033 Non-core contributed modules project]. | ||
# Add the release date to | # Add the release date and link to [[Releases]] | ||
# Notify all registered sys admins | # Notify all registered sys admins | ||
# Clone MDL-28314 for next minor release X.Y.1 handling of security issues & security advisories. | # Clone MDL-28314 for next minor release X.Y.1 handling of security issues & security advisories. | ||
Revision as of 13:11, 1 August 2011
This page describes the standard procedures for making Moodle releases.
For a stable release on an existing branch XX with point value Y
One week before:
- Notify Moodle developers and Moodle Partners about the upcoming release
- 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.
- Test / QA etc
Release day: (exactly before the next integration cycle begins on Monday)
- Make sure all the Unit tests pass!
- Edit version.php, update name and version to new point release and commit in the integration repository
- Run the mdlrelease process, that will do, for a release:
- Tag the integration repository with a tag name vX.Y.Z using "MOODLE_XXY" as a tag message
- push change to main git repo, github and Gitorious
- sync CVS mirror (copy the version.php file and update githash.php to point to the release commit)
- cvs tag -FR MOODLE_XXY to tag everything in the release
- cvs tag -FR MOODLE_XX_WEEKLY to make the weekly version match the release
- cvs -q update -dP all code on download server
- Run moodle-makenightlystableXX
- Go to download/stableXX
- Copy current daily as release package:
- cp moodle-latest-XX.zip moodle-X.X.Y.zip
- cp moodle-latest-XX.tgz moodle-X.X.Y.tgz
- Edit download index.php page with new release info and links
- Run moodle-makewindowspackages so all the windows packages will be rebuilt
- Edit download windows/index.php page with new release info (always keeping the "+")
- Visit releases page on tracker and make the release, bumping all remaining open bugs to the next point release. This must be done both for the Moodle Project and the Non-core contributed modules project.
- Add the release date and link to Releases
- Notify all registered sys admins
- Clone MDL-28314 for next minor release X.Y.1 handling of security issues & security advisories.
One week later:
- Update the version.php in git to be X.X.Y+ during the next weekly PULL process
- Add all security advisories to Security news and release notes with links to security advisories
- Update the Latest Release block on Moodle.org news
- Post about the release in the moodle.org news
- Create a new release notes page for the next version XX.Y+1 (here you can find one template for that)
See also
- Stable branch support
- Major release process
- MDLSITE-699: How to repackage one weekly at any moment (a.k.a. "emergency weekly").
