Note: You are currently viewing documentation for Moodle 3.4. Up-to-date documentation for the latest stable version of Moodle is likely available here: Release process.

Development:Release process: Difference between revisions

From MoodleDocs
 
(43 intermediate revisions by 5 users not shown)
Line 1: Line 1:
Some notes on the release process, to be fleshed out.
This page describes the standard procedures for making Moodle releases.


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


# Test / QA / etc
One week before:
# '''cvs -q update -dP'''
# Notify Moodle developers and Moodle Partners about the upcoming release
# Edit version.php, update name and version to new point release and commit
# Freeze stable development and post in the [http://moodle.org/mod/forum/view.php?id=55 General developer forum] to inform everyone of the freeze
# '''cvs tag -FR MOODLE_XXY version.php'''
# Review and complete the [[:Category:Release notes|release notes]] of the upcoming version.
# '''cvs tag -F MOODLE_XX_MERGED version.php'''
# [[Development:Weekly Code Review|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 [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
#* 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
# '''cvs -q update -dP''' all code on download server
# Run moodle-makenightlystableXX
# Run moodle-makenightlystableXX
Line 15: Line 25:
## '''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
# Visit releases page on tracker and make the release, bumping all remaining open bugs to the next point release.
# Run moodle-makewindowspackages so all the windows packages will be rebuilt
# Update filters (like Moodle 1.8.x bugs) in the tracker to include new unreleased versions
# Edit download windows/index.php page with new release info (always keeping the "+")
# Make sure the [[Release Notes]] page is updated
# 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].
# Make sure all security bugs are posted on [http://moodle.org/security Security news]
# Add the release date to the [[:Category:Release notes|release notes]]
# Add new version on the [[Release]] page
# Update the [[Latest release notes]] page
# Update the version.php in CVS to be X.X.Y+
# Add the new version to the [[Moodle version history]] page
# '''cvs tag -F MOODLE_XX_MERGED version.php'''
# Include the new versions in [[Moodle 1.8 release notes]], [[Moodle 1.9 release notes]] and [[Moodle 2.0 release notes]]
# Post about the release on [http://moodle.org Moodle.org] front page
# Notify all registered sys admins
# Create a new ('''blocker serious security issue!''') 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-20840 (for Moodle 1.9.7).
# Create a new ('''blocker serious security issue!''') task in the Tracker "Prepare security advisories for XX.Y+1 and friends" to define/edit/polish the security advisories in the next release. Link it with the previous one as "will be resolved by". An example is MDL-20722 (for Moodle 1.9.7).
 
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 [http://moodle.org/security Security news]
# Add all security issues to the [[:Category:Release notes|release notes]] with links to security advisories
# 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]
# Create a new release notes page for the next version XX.Y+1 (here you can find [[Development:Release notes template|one template for that]])
 
==See also==
 
* [[Development:Stable branch support]]
* [[Development:Major release process]]
* MDLSITE-699: How to repackage one weekly at any moment (a.k.a. "emergency weekly").
 
[[Category:Processes|Release process]]
[[Category:Release notes|Release process]]

Latest revision as of 14:19, 6 May 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:

  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.
  4. Test / QA etc

Release day: (exactly before the next integration cycle begins on Monday)

  1. Make sure all the Unit tests pass!
  2. Edit version.php, update name and version to new point release and commit in the integration repository
  3. 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
  4. cvs -q update -dP all code on download server
  5. Run moodle-makenightlystableXX
  6. Go to download/stableXX
  7. 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
  8. Edit download index.php page with new release info and links
  9. Run moodle-makewindowspackages so all the windows packages will be rebuilt
  10. Edit download windows/index.php page with new release info (always keeping the "+")
  11. 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.
  12. Add the release date to the release notes
  13. Update the Latest release notes page
  14. Add the new version to the Moodle version history page
  15. Include the new versions in Moodle 1.8 release notes, Moodle 1.9 release notes and Moodle 2.0 release notes
  16. Notify all registered sys admins
  17. Create a new (blocker serious security issue!) 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-20840 (for Moodle 1.9.7).
  18. Create a new (blocker serious security issue!) task in the Tracker "Prepare security advisories for XX.Y+1 and friends" to define/edit/polish the security advisories in the next release. Link it with the previous one as "will be resolved by". An example is MDL-20722 (for Moodle 1.9.7).

One week later:

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

See also

Retrieved from "https://docs.moodle.org/34/en/index.php?title=Development:Release_process&oldid=83304"
Powered by MediaWiki