Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Archive release process: Difference between revisions

From MoodleDocs
(Adding clarity to timeline)
(Use X, Y, Z along the whole page to make it consistent for any minor release)
Line 1: Line 1:
This page describes the standard procedures for making Moodle releases.
This page describes the standard procedures for making Moodle releases.


==For a stable release on an existing branch X with point value Y (eg. 2.X.Y)==
==For a stable release on an existing branch XY with point value Z (eg. X.Y.Z)==


===One week before===
===One week before===
Line 18: Line 18:
# Edit version.php, update name and version to new point release and commit in the integration repository
# Edit version.php, update name and version to new point release and commit in the integration repository
# Run the [https://github.com/skodak/mdlrelease/blob/master/weeklybuild.txt mdlrelease] process, that will do, for a release:
# Run the [https://github.com/skodak/mdlrelease/blob/master/weeklybuild.txt 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  
#* Tag the integration repository with a tag name vX.Y.Z using "MOODLE_XYZ" as a tag message  
#* push change to main git repo, github and Gitorious
#* 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)
#* 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_XYZ''' to tag everything in the release
#* '''cvs tag -FR MOODLE_XX_WEEKLY''' to make the weekly version match the release
#* '''cvs tag -FR MOODLE_XY_WEEKLY''' to make the weekly version match the release
# '''cvs -q update -dP''' all code on download server
# '''cvs -q update -dP''' all code on download server
# Run moodle-makenightlystableXX
# Run moodle-makenightlystableXY
# Go to download/stableXX 
# Go to download/stableXY
# Copy current daily as release package:
# Copy current daily as release package:
#* '''cp moodle-latest-XX.zip moodle-X.X.Y.zip'''
#* '''cp moodle-latest-XY.zip moodle-X.Y.Z.zip'''
#* '''cp moodle-latest-XX.tgz moodle-X.X.Y.tgz'''
#* '''cp moodle-latest-XY.tgz moodle-X.Y.Z.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
# Run moodle-makewindowspackages so all the windows packages will be rebuilt
Line 36: Line 36:
# Add the release date and link to [[Releases]]
# Add the release date and link to [[Releases]]
# Notify all registered sys admins
# Notify all registered sys admins
# Clone MDL-30488 for next minor release X.Y+1 handling of security issues & security advisories.
# Clone MDL-30488 for next minor release X.Y.(Z+1) handling of security issues & security advisories.


===One week after release day===
===One week after release day===
# Update the version.php in git to be X.X.Y+ during the next weekly integration process
# Update the version.php in git to be X.Y.Z+ during the next weekly integration process
# Add all security advisories to [http://moodle.org/security Security news] and [[:Category:Release notes|release notes]] with links to security advisories
# Add all security advisories to [http://moodle.org/security Security news] and [[:Category:Release notes|release notes]] with links to security advisories
# Update the Latest Release block on [http://moodle.org/news/ Moodle.org news]
# Update the Latest Release block on [http://moodle.org/news/ Moodle.org news]
# Post about the release in the [http://moodle.org/news/ moodle.org news]
# Post about the release in the [http://moodle.org/news/ moodle.org news]
# Create a new release notes page for the next version XX.Y+1 (here you can find [[Release notes template|one template for that]])
# Create a new release notes page for the next version X.Y.(Z+1) (here you can find [[Release notes template|one template for that]])


==See also==
==See also==

Revision as of 15:46, 7 January 2012

This page describes the standard procedures for making Moodle releases.

For a stable release on an existing branch XY with point value Z (eg. X.Y.Z)

One week before

  1. Notify Moodle developers and Moodle Partners about the upcoming release
  2. Freeze stable development and post in the General developer forum to inform everyone of the freeze
  3. Review and complete the release notes of the upcoming version using the template
  4. Test / QA etc.

During the week prior release

  1. Normal integration / testing / upstream / weekly cycle. It will constitute, somehow, the "release candidate" to be packaged the release day.

Release day

This should happen immediately before the next integration cycle begins on Monday (i.e., some days after last weekly).

  1. Make sure there are not real blockers introduced by last weekly (install / upgrade ...)
  2. Make sure all the Unit tests pass!
  3. Edit version.php, update name and version to new point release and commit in the integration repository
  4. Run the mdlrelease process, that will do, for a release:
    • Tag the integration repository with a tag name vX.Y.Z using "MOODLE_XYZ" 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_XYZ to tag everything in the release
    • cvs tag -FR MOODLE_XY_WEEKLY to make the weekly version match the release
  5. cvs -q update -dP all code on download server
  6. Run moodle-makenightlystableXY
  7. Go to download/stableXY
  8. Copy current daily as release package:
    • cp moodle-latest-XY.zip moodle-X.Y.Z.zip
    • cp moodle-latest-XY.tgz moodle-X.Y.Z.tgz
  9. Edit download index.php page with new release info and links
  10. Run moodle-makewindowspackages so all the windows packages will be rebuilt
  11. Edit download windows/index.php page with new release info (always keeping the "+")
  12. Run SF's mirror script
  13. 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.
  14. Add the release date and link to Releases
  15. Notify all registered sys admins
  16. Clone MDL-30488 for next minor release X.Y.(Z+1) handling of security issues & security advisories.

One week after release day

  1. Update the version.php in git to be X.Y.Z+ during the next weekly integration process
  2. Add all security advisories to Security news and release notes with links to security advisories
  3. Update the Latest Release block on Moodle.org news
  4. Post about the release in the moodle.org news
  5. Create a new release notes page for the next version X.Y.(Z+1) (here you can find one template for that)

See also