Development:Release process: Difference between revisions
From MoodleDocs
No edit summary |
m (adding info to release also windows downloads) |
||
Line 22: | Line 22: | ||
## '''cp moodle-latest-XX.tgz moodle-X.X.Y.tgz''' | ## '''cp moodle-latest-XX.tgz moodle-X.X.Y.tgz''' | ||
# Edit download index.php page with new release info and links | # 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. | # Visit releases page on tracker and make the release, bumping all remaining open bugs to the next point release. | ||
# Update the version.php in CVS to be X.X.Y+ | # Update the version.php in CVS to be X.X.Y+ |
Revision as of 18:14, 21 October 2009
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
- Test / QA / etc
Release day:
- cvs -q update -dP
- Make sure all the Unit tests pass!
- Edit version.php, update name and version to new point release and commit
- cvs tag -F MOODLE_XX_MERGED version.php
- 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.
- Update the version.php in CVS to be X.X.Y+
- cvs tag -F MOODLE_XX_MERGED version.php
- Make sure the Release Notes page is updated
- Add new version on the Release page
- Notify all registered sys admins
- 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:
- Add all security notices to Security news
- Add all security notices to the Release Notes page
- Post about the release on Moodle.org front page
For a major release XX
- To be documented
See also
- Development:Stable branch support
- MDLSITE-699: How to repackage one weekly at any moment (a.k.a. "emergency weekly").