Development:Release process

The standard procedures for making Moodle releases.

For a stable release on an existing branch XX with point value Y

One week before:

1. Notify Moodle developers and Moodle Partners about the upcoming release
2. Freeze stable development
3. Test / QA / etc

Release day:

1. cvs -q update -dP
2. Make sure all the Unit tests pass!
3. Edit version.php, update name and version to new point release and commit
4. cvs tag -F MOODLE_XX_MERGED version.php
5. cvs tag -FR MOODLE_XXY to tag everything in the release
6. cvs tag -FR MOODLE_XX_WEEKLY to make the weekly version match the release
7. cvs -q update -dP all code on download server
8. Run moodle-makenightlystableXX
9. Go to download/stableXX
10. Copy current daily as release package:
    1. cp moodle-latest-XX.zip moodle-X.X.Y.zip
    2. cp moodle-latest-XX.tgz moodle-X.X.Y.tgz
11. Edit download index.php page with new release info and links
12. Run moodle-makewindowspackages so all the windows packages will be rebuilt
13. Edit download windows/index.php page with new release info (always keeping the "+")
14. Visit releases page on tracker and make the release, bumping all remaining open bugs to the next point release.
15. Update the version.php in CVS to be X.X.Y+
16. cvs tag -F MOODLE_XX_MERGED version.php
17. Make sure the Release Notes page is updated
18. Add new version on the Release page
19. Notify all registered sys admins
20. Create a new META bug in the Tracker "META: Moodle XX.Y+1 and friends security bugs" to associate new/pending security bugs that will be fixed in the next release as subtasks. An example is MDL-19512 (for Moodle 1.9.6).

One week later:

1. Add all security notices to Security news
2. Add all security notices to the Release Notes page
3. Post about the release on Moodle.org front page

For a major release XX

1. To be documented

See also

• Development:Stable branch support
• MDLSITE-699: How to repackage one weekly at any moment (a.k.a. "emergency weekly").