Release process: Difference between revisions
From MoodleDocs
(Adding link to mailing list server) |
m (added full demo week countdown) |
||
Line 537: | Line 537: | ||
| | | | ||
* Publish the calendar for next Major release (for the next 6-months period: ~1 month bugfixing and planning, ~4 months of development, ~1 month for QA, candidates/betas/release). | * Publish the calendar for next Major release (for the next 6-months period: ~1 month bugfixing and planning, ~4 months of development, ~1 month for QA, candidates/betas/release). | ||
* 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 -5w and -4w before release date respectively. | * 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 upcoming dates on the [[Roadmap]] page. | * Update upcoming dates on the [[Roadmap]] page. | ||
| [[#dev|Development Manager]] | | [[#dev|Development Manager]] |
Revision as of 23:15, 5 March 2014
Roles
Role | Person responsible |
---|---|
Lead Developer | Martin Dougiamas |
Integration Lead | Eloy Lafuente |
Community Manager | Helen Foster |
AMOS Maintainer | David Mudrák |
Moodle Docs Maintainer | David Mudrák |
Plugins Directory Maintainer | Aparup Banerjee |
Testing Maintainer | David Monllaó |
QA Master Site Maintainer | Helen Foster |
Digital Marketing Specialist | X.Y. Ng |
System Administrator | Matthew Spurrier |
Development Manager | Michael de Raadt |
Roles updated 18 June 2013.
7 weeks prior
# | Major | Minor | Task | Responsibility |
---|---|---|---|---|
1. | ✓ | Full demo of new code and sign-off | 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. | ✓ | Freeze stable development and post in the General developer forum to inform everyone of the freeze. (example) | Development Manager | |
4. | ✓ | Check qa_test_required-labelled issues and create new QA tests as required. | Community Manager | |
5. | ✓ |
|
Testing Maintainer |
5 weeks prior
# | Major | Minor | Task | Responsibility |
---|---|---|---|---|
1. | ✓ | Announce code-freeze | Development manager |
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:
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; release STABLE weeklies normally but master release as often as possible (or on demand). | Integration Lead | |
5. | ✓ | At some points produce release candidates (Z = 1, 2, 3..), which are normal builds with:
|
Integration Lead | |
6. | ✓ | Add a new version in the Plugins Directory with the beta version build number and the anticipated release version build number (https://moodle.org/plugins/admin/softwareversions.php). | Plugins Directory Maintainer | |
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. | ✓ | Prepare a fresh installation of the QA Master 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 | |
9. | ✓ | Create new QA test cycle and invite community volunteers to start QA testing. | Community Manager | |
10. | ✓ | Update the QA testing dashboard. | Development Manager | |
11. | ✓ | 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 | |
12. | ✓ | 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. | ✓ |
|
Development Manager |
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-42701 and bump all versions, requires and dependencies along all plugins in codebase to current date. | 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. | Digital Marketing Specialist |
6. | ✓ | ✓ | Merge fixes from en_fix pack and then integrate them. | AMOS Maintainer |
7. | ✓ | In https://github.com/moodlehq/moodle-behat-extension project:
|
Testing Maintainer | |
8. | ✓ | ✓ | Identify security issues that need to be integrated using the security_held label.
|
Integration Lead |
9. | ✓ | ✓ | Collect security issues into a clone of MDL-39530 to prepare for release of Security Advisories.
|
Development Manager |
10. | ✓ | ✓ | Review and complete the release notes for the upcoming minor versions.
|
Development Manager |
11. | ✓ | Check on the "Must fix for X.Y version". Filter out unrealistic issues. | Development Manager | |
12. | ✓ | Upgrade moodle.org (test server first, then production) | System Administrator |
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. | ✓ | ✓ | For major releases only:
Follow the "mdlrelease" steps:
|
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 successfuly (email).
For major releases only:
|
Integration Lead |
8. | ✓ | ✓ | On the download server:
For major releases only:
|
Integration Lead |
9. | ✓ | ✓ | In the Tracker...
|
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. Reindex Tracker. | Integration Lead | |
11. | ✓ | Clone MDL-42929, MDL-42930 and MDL-42931, to be resolved ASAP. | Integration Lead | |
12. | ✓ | ✓ | Add/update the release date, build number and link on the Releases page and date in new version pages. | 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. | ✓ | ✓ | Replace the download/index.php page with its updated counterpart. | Integration Lead |
3. | ✓ | ✓ | Replace the download/windows/index.php page with its updated counterpart. | 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. | Digital Marketing Specialist |
8. | ✓ | New "X.Y+1dev" branch to be created in AMOS, to have master changes performed there. This 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, enable email notifications and add version links to https://docs.moodle.org/overview/. | Moodle Docs Maintainer | |
11. | ✓ | Go through all points listed under Day of release in New docs version process. | Community Manager | |
12. | ✓ |
|
Development Manager | |
13. | ✓ | ✓ | Upgrade all moodle.org and moodle.net sites to latest release version. | System Administrator |
14. | ✓ | Add calendar events in the moodle.org calendar for coming Major and Minor releases up to the next Major release. | Community Manager |
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.) | 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...
...followed by the security notes. |
Development Manager |
1 month after
# | Major | Minor | Task | Responsibility |
---|---|---|---|---|
1. | ✓ | Publish the X.(Y+1)dev packages for download.moodle.org | Integration Lead |