Development:Release process: Difference between revisions
From MoodleDocs
mNo edit summary |
|||
| Line 6: | Line 6: | ||
# Notify Moodle developers and Moodle Partners about the upcoming release | # Notify Moodle developers and Moodle Partners about the upcoming release | ||
# Freeze stable development | # Freeze stable development | ||
# Review and complete the Release Notes page of the upcoming version. | |||
# Test / QA / etc | # Test / QA / etc | ||
| Line 28: | Line 29: | ||
# '''cvs tag -F MOODLE_XX_MERGED version.php''' | # '''cvs tag -F MOODLE_XX_MERGED version.php''' | ||
# Make sure the [[Release Notes]] page is updated | # Make sure the [[Release Notes]] page is updated | ||
# Add new version on the [[Release]] page | # Add new version on the [[Release]] page. | ||
# Notify all registered sys admins | # 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). | # 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). | ||
| Line 37: | Line 38: | ||
# Add all security notices to the [[Release Notes]] page | # Add all security notices to the [[Release Notes]] page | ||
# Post about the release on [http://moodle.org Moodle.org] front page | # Post about the release on [http://moodle.org Moodle.org] front page | ||
# Create one new release notes page for the next version XX.Y+1 (here you can find [[Development:Release notes template|one template for that]]) | |||
===For a major release XX=== | ===For a major release XX=== | ||
Revision as of 15:36, 2 November 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
- Review and complete the Release Notes page of the upcoming version.
- 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. This must be done both for the Moodle Project and the Non-core contributed modules project.
- 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
- Create one new release notes page for the next version XX.Y+1 (here you can find one template for that)
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").
