Note:

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

Major release process

From MoodleDocs
Revision as of 11:10, 7 April 2010 by Helen Foster (talk | contribs) (content copied from Release_process)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Note: This page is a work-in-progress. Feedback and suggested improvements are welcome. Please join the discussion on moodle.org or use the page comments.


This page describes the standard procedures for making a major release e.g. Moodle 2.0.

Beta release

To be documented...

  1. Test / QA etc

Final release

Additional points to be added...

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.

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. This must be done both for the Moodle Project and the Non-core contributed modules project.
  15. Update the version.php in CVS to be X.X.Y+
  16. cvs tag -F MOODLE_XX_MERGED version.php
  17. Add the release date to the release notes
  18. Update the Latest release notes page
  19. Add the new version to the Moodle version history page
  20. Include the new versions in Moodle 1.8 release notes, Moodle 1.9 release notes and Moodle 2.0 release notes
  21. Notify all registered sys admins
  22. 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).
  23. 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. Add all security advisories to Security news
  2. Add all security issues to the 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 XX.Y+1 (here you can find one template for that)

See also

Retrieved from "https://docs.moodle.org/dev/index.php?title=Major_release_process&oldid=17529"
Powered by MediaWiki