Release process

Revision as of 11:13, 5 October 2015 by Marina Glancy (talk | contribs) (5 weeks prior)

Jump to: navigation, search

8 weeks prior

# Major Minor Task Responsibility
1. Create an issue to review latest stable version of all third party libraries and add to sprint. The issue should refer to the list at Moodle libraries credits. The issue can be based on MDL-47147. Development Manager
2. Ensure we are running latest/good behat version. Testing Maintainer
3. Move QA tests for new features in old release with automated tests from MDLQA-1 to MDLQA-5249. Testing Maintainer

7 weeks prior

# Major Minor Task Responsibility
1. Full demo of new code and sign-off for internal HQ projects. Decide which projects will be completed by the code freeze. Lead Developer

6 weeks prior

# Major Minor Task Responsibility
1. Create the next "X.Y+1" (next dev) version in the Tracker (MDL and CONTRIB), so people can move delayed stuff to next major release if needed. Integration Lead
2. Create a "Must fix for X.Y" version in the tracker. Integration Lead
3. Warn external developers about the impending code freeze in a post to the General developer forum. (example) Development Manager
4. Check closed qa_test_required-labelled issues and create new QA tests as required. If features has automated tests then set priority to blocker and link the issue as "is a QA written for" Testing Maintainer

5 weeks prior

# Major Minor Task Responsibility
1. Confirm the code freeze by replying to the previous warning in the General developer forum. Development manager
2. Once the integration server has ended with Monday's job Move awaiting issues to current integration it will be disabled and, issues will be manually picked for integration until the post-release "On Sync" period ends (usually 3 weeks after release). Integration Lead
3. Prepare a fresh installation of the QA site based on the beta code to make sure the site is not affected by incremental upgrade steps during the development cycle. QA Master Site Maintainer
4. Write documentation on new features in the dev docs, adding a link to it from the tracker issue, together with the label docs_required. The documentation will then be transferred to the new en version wiki when it is set up (3 weeks prior) and polished, with screenshots added. Developers, Development manager to remind

4 weeks prior

# Major Minor Task Responsibility
1. Start working on the release notes (template) of the upcoming version. Development Manager
2. Release normal weeklies but with these changes in the master branch:
  • version.php: Move to $maturity = MATURITY_BETA and $release = 'X.Ybeta (Build:xxxxxxxx)'
  • tag git repo with: "vX.Y.0-beta" (and MOODLE_XY_BETA as description and CVS tag)

And make packages available under download.moodle.org (and windows). Promote master up in the download page and adjust info for it.

Integration Lead
3. (Optionally) Announce Beta release in forums (ideally once packages are available). Integration Lead
4. During the QA weeks integration becomes continuous; roll (on demand, beta, rc...) happens often (Tuesday & Friday are the usual days). Integration Lead
5. At some points produce release candidates (Z = 1, 2, 3..), which are normal builds with:
  • version.php: Move to $maturity = MATURITY_RC and $release = 'X.YrcZ (Build:xxxxxxxx)'
  • tag git repo with: "vX.Y.0-rcZ" (and MOODLE_XY_RCZ as description and CVS tag)
  • Make packages available under download.moodle.org (and Windows).
Integration Lead
6. Add a new version in the Plugins Directory with the version's name and the beta release version build number (https://moodle.org/plugins/admin/softwareversions.php). Plugins Liaison
7. Tidy up current latest en version of Moodle Docs prior to copying it to create new version wiki as described in New docs version process. Community Manager
8. Create new QA test cycle and post in development forum about QA testing. Testing Manager
9. Invite community volunteers to start QA testing. Community Manager
10. Monitor QA fails. Check each fail is real and if so ensure an MDL issue has been created and correctly linked and labelled. Testing Maintainer
11. Monitor MDL issues created for QA fails. Add them to the "Must fix for X.Y" list and get a developer to work on the issue immediately. Development Manager

3 weeks prior

# Major Minor Task Responsibility
1. Prompt developers to begin QA tests marked test_server_required. Development Manager
2. Create new en and de Moodle Docs version wikis. Moodle Docs Maintainer
3. Check docs_required-labelled issues and write new documentation, removing the label and commenting in the issue when the work is done. Community Manager
4. Go through all points listed under 3 weeks prior in New docs version process. Community Manager
5. Review issues with labelled with dev_docs_required, prompting assigned developers to create/update this documentation and remove this label when relevant docs are updated. Development Manager

2 weeks prior

# Major Minor Task Responsibility
1.
  • Prompt developers to complete remaining QA tests.
  • Ensure all QA tests are completed and passed by the end of the week.
Development Manager
2.

Create MDLSITE issue to ensure all prototype.moodle.net sites which are no longer relevant (part of release) are removed from prototype.moodle.net

Development Manager
3. Merge fixes from en_fix pack and then integrate them. AMOS Maintainer

1 week prior

# Major Minor Task Responsibility
1. Clone as many filters as needed in the Tracker, modifying them to point to the new, upcoming, branch (keeping same perms, title...). Integration Lead
2. Create new minor version X.Y.Z+1 in the Tracker (MDL and CONTRIB). Archive any version > 6 months old. Integration Lead
3. Clone MDL-50102 and bump all versions, requires and dependencies along all plugins in codebase to planned release dates. Integration Lead
4. Post a "Heads-up" message on the Partners forum and General Developer forum. Development Manager
5. Post a "Heads-up" message on Twitter and other outlets. Marketing Officer
6. Identify security issues that need to be integrated using the security_held label.
  • Integrate from provided patches into supported branches (including branches supported only for security issues).
  • Ensure security issues are given priority in weekly integration and testing.
Integration Lead
7. Collect security issues into a clone of the last advisory in the list to prepare for release of Security Advisories.
  • Determine which security issues will be integrated.
  • Request CVE Identifiers by emailing issue descriptions to secalert@redhat.com with a message like... The following security issues have been discovered in Moodle. We request CVE Identifiers for these issues. We will be releasing the security announcements for these on moodle.org on XXX at 12noon AWST which is 04:00 UTC. The email subject should include the characters [vs]. The format needs to be plain text or encrypted. When granted CVE Identifiers, our issues should appear in the CVE list. More instructions are available (since 2015 we request identifiers from redhat and not from distros).
  • Post security issues as a reply to the "Heads-up" message on the Partners forum.
Development Manager
8. Review and complete the release notes for the upcoming minor versions.
  • Ensure all issues labelled with "ui_change", "api_change" and "release_notes" are listed as UI changes, functional changed and fixes/improvements respectively in the release notes.
Development Manager
9. Check on the "Must fix for X.Y version". Filter out unrealistic issues. Development Manager
10. Upgrade moodle.org to beta release
11. Upgrade moodle.org and all other Moodle community sites (next sites first, then production) - Friday before release if not before

Releasing

Packaging

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

# Major Minor Task Responsibility
1. Make sure there are no real blockers introduced in the last weekly (install / upgrade ...). Confirm that the latest en_fix changeshave been generated and integrated. Integration Lead
2. Verify all unit tests and integration tests have passed. Integration Lead
3. Verify QA tests have passed. Integration Lead
4. Follow the "mdlrelease" steps:
  • Run the prerelease.sh script to generate the target minor (--type minor) and major (--type major) releases and their corresponding tags. Follow the on-screen instructions. Triple verify all changes are correct!
  • Push changes to integration.git (but tags).

For major releases only:

  • Configure "mdlrelease" (config.sh) to know about the new MOODLE_XY+1 stable branch.
  • Update the CI server(s) by cloning all the "master" jobs to a new "MXY" view. Adjust "master" compare DB jobs to check for upgrade from MOODLE_XY_STABLE. Don't forget to re-chain the jobs properly. Run them.
   Important note: don't forget to disable memcached application store for unit tests in stable branches. (more info).

Continue with the "mdlrelease" steps:

  • Once CI servers have ended and all jobs have passed, push tags and run the release.sh script to apply the changes to moodle.git.
  • If needed configure "mdlrelease" (config.sh) to get rid of any unsupported version and adjust stable and security branches. Make a pull request with the changes.
Integration Lead
5. Post a "git repos updated & tagged" message on the Partner forum Integration Lead
6. Create a new MOODLE_XY+1_STABLE branch in https://github.com/moodlehq/moodle-performance-comparison and set the new release commit hash as $basecommit Testing Maintainer
7. Wait for the automated moodle-package to finish building for all versions. Verify the process has ended successfully (email).

For major releases only:

  • Use the prerelease.sh script (--type back-to-dev) to move master to next X.Y+1 development version/branch. And push changes to integration.git - note this will lead to the "versions checker" failing for master, no problem, it will be fixed by the 1st cloned issue at #12 below).
  • Once CIs have ended, use the "release.sh" script to send those master changes to moodle.git.
Integration Lead
8.
  • Create new windows packager script (cloning the current master one and configuring it).
  • Create new windows_wpiXY dir by cloning the previous one (HEAD based), configuring build-latest-XY.sh.
  • Edit the stats.php script (in the moodle-local_downloadmoodleorg repository), adding the new branch to the versions. Deploy it.
Integration Lead
9. In the Tracker...
  • Visit the versions page and make the release, bumping all remaining open bugs to the next point release. If there is not next (end of support), clean that version from all the issues having it as "Fix for". This must be done both for the Moodle Project and the Plugins project. Archive any version > 6 months old.
  • Remove from all screens the custom fields belonging to 100% unsupported branches.

For major releases only:

  • Release and package the "Must fix for X.Y" versions, it must be empty to do so.
Integration Lead
10. Create the new "Pull X.Y Branch" and "Pull X.Y Diff URL" custom fields and spread them to all the screens needing them (copy from previous ones). Order them properly on each screen. Re-index Tracker.

Also, in the CI servers (1, 2), edit the "Bulk precheck issues" job to make it meet the new "Pull X.Y Branch" field created.

Integration Lead
11. In the Tracker...
  • Verify how the "X.Y regressions" versions are going and ping Development Managers about. Package and archive them once empty.

For major releases only:

  • Create the new "X.Y regressions" version to be applied to every issue found to be a recent problem introduced by the major release. These issues should get priority after release.

Adjust the filter Latest regressions

Integration Lead
12. Clone MDL-50184 and MDL-50183, to be resolved ASAP. Integration Lead
13. Add/update the release date, build number and link on the Releases page and date in new version pages. Integration Lead
14. Create the new security-MOODLE_XY_STABLE and lastbased-MOODLE_XY_STABLE branches in the security report (branching from the just created MOODLE_XY_STABLE branch). Integration Lead
15. Protect the MOODLE_XY_STABLE branches in github interface to prevent non-FF accidents ( MDLSITE-4183 ) Integration Lead

Release day

Usually on Monday

# Major Minor Task Responsibility
1. The execution of "moodle-package-extract-and-postprocess X" script may be needed if the releases *are not going to be published on Monday* but another weekday (X is the weekday, (1-7) starting in Monday). By default it happens automatically around 09:00 AM Perth/Australia time. Integration Lead
2. Verify release status, download pages and windows packages. Integration Lead
3. If needed, modify the downloads cfg script (serverscripts) to decide about branches status, master visibility and windows availability. Push changes, will be autodeployed in a few minutes. Integration Lead
4. Notify all registered sys admins, including security notes with CVE identifiers, using the mailing list server. Development Manager
5. Post about the Major release on the moodle.org News forum Lead Developer
6. Post about minor releases on the moodle.org News forum Development Manager
7. Post about the release on Twitter and other outlets. Update no. of releases on moodle.com 'Fact Sheet' page: http://moodle.com/news/moodle-fact-sheet/ Digital Marketing Specialist
8. New "X.Y+1dev" branch to be created in AMOS, to have master changes performed there. New install_XY_STABLE processing set up. These needs to be done anytime during the on-sync period. AMOS Maintainer
9. Verify, 24h after tagging, that https://moodle.org/dev/ has been updated with new versions. If not, file an urgent mdlsite issue, crons must be running! Integration Lead
10. For en and de Moodle Docs, update default redirects and enable email notifications. Moodle Docs Maintainer
11. Go through all points listed under Day of release in New docs version process. Community Manager
12.
  • Decide the "Full demo", "Code freeze" and "QA begins" dates for the next X.(Y+1) major release and put them in the Moodle development calendar. They will be -7w, -5w and -4w before release date respectively.
  • Update the "Full demo", "Code freeze", "QA begins" and Release dates on the Roadmap page.
  • Add events to the HQ calendar for next Major release 6-months cycle according to the cycle plan: ~4 weeks planning and regression fixing, 2 sprints, 1 personal project week, 2 sprints, 1 personal project week, 1 sprint (which should lead up to code freeze).
  • Notify the Community Manager of new dates to be added to the moodle.org calendar.
Development Manager
13. Add calendar events in the moodle.org calendar for coming Major and Minor releases up to the next Major release. Community Manager
14. Add $CFG->skiplangupgrade = 1; to master acceptance test on nightly (apache01 & phantom01), as language pack is not available during on-sync for master. Testing Maintainer

1 week after

# Major Minor Task Responsibility
1. Publish the X.Y+ packages for download.moodle.org (should be automatic once weeklies are packaged). Integration Lead
2. Update the version.php in git to be X.Y.Z+ during the next weekly integration process Integration Lead
3. Create a new release notes page for the next minor versions (using the release notes template.) Add note to top of relevant version page about security support. Development Manager
4. Add all security advisories to Security news and release notes with links to security advisories Development Manager
5. Send a plain text email to the OSS mailing list: oss-security@lists.openwall.com. An appropriate message when sending the issues is...
The following security notifications have now been made public. Thanks to OSS members for their cooperation.

...followed by the security notes.

Development Manager
6. Upgrade moodle.org and all other Moodle community sites (next sites first, then production)
7. Create nightly jobs for the XY branch (Refer doc [1]) and disable it after running jobs for day or two, so as to conserve resources on nightly Testing Maintainer
7. Clone this issue for next major release - MDL-48470 Integration Lead

3 weeks after

# Major Minor Task Responsibility
1. Once the "On Sync" period ends:
  • The "integration_held" label will be removed from issues awaiting integration, so they will be, automatically (see next point), be moved to current integration. Send a "rebase" message to all those issues.
  • The "Move awaiting issues to current integration" job will be re-enabled in the public CI server.
  • The discussion about environmental requirements for next X.Y+1 major release (MDL-51580) will end and the issue will be resolved immediately. A new issue, about the requirements for next-next X.Y+2 major release will be created at the same time by cloning the previous one and dragging any non-resolved detail.
Integration Lead
2. In https://github.com/moodlehq/moodle-behat-extension project:
  • For the new stable version:
    1. Create a MOODLE_XY_STABLE branch from master
  • For master:
    1. Add a 1.X(Y+1).0 tag for the new release in the master branch
    2. Clone MDL-39489, implement, and send it to integration.
Testing Maintainer
3. Ensure Language pack for master is available and remove $CFG->skiplangupgrade = 1; for master on nightly (apache01 and phantom01) Testing Maintainer
4. Enable nightly jobs for the XY. Testing Maintainer

1 month after

# Major Minor Task Responsibility
1. Publish the X.(Y+1)dev packages for download.moodle.org Integration Lead

See also