Note:

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

Release process: Difference between revisions

From MoodleDocs
(Created page with "{{draft}} ==Six weeks prior== {| class="nicetable" style="width:100%" |- ! # ! Major ! Minor ! Task ! style="width:12%" | Responsibility |- | 1. | style="text-align:center" | &#...")
 
(Added more tasks - still a work in progress)
Line 156: Line 156:
==Day of release==
==Day of release==
===Packaging===
===Packaging===
{| class="nicetable" style="width:100%"
|-
! #
! Major
! Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| Make sure there are no real blockers introduced in the last weekly (install / upgrade ...)
| Integration Lead
|-
| 2.
| style="text-align:center" | ✓
|
| Verify all unit tests, QA tests and integration tests have passed.
| Integration Lead
|-
| 3.
| style="text-align:center" | ✓
|
| Run the [https://github.com/moodlehq/mdlrelease/blob/master/weeklybuild.txt mdlrelease] process, with the [https://github.com/moodlehq/mdlrelease/blob/master/releasemajor.txt special steps] for a Major release.
* Edit version.php, update release and version to new release values and commit in the integration repository.
* Tag the integration repository with a tag name vX.Y.0 using "MOODLE_XY" as a tag message.
* Create the new MOODLE_XY_STABLE branch.
* Move master to next X.Y+1 version.
* 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.
* Push changes to the main Git repo, Github and Gitorious.
| Integration Lead
|-
| 4.
| style="text-align:center" | ✓
|
| Wait for the automated moodle-package to finish building for all versions. Verify the process has ended successfuly (email).
| Integration Lead
|-
| 5.
| style="text-align:center" | ✓
|
| In the download server:
* Duplicate the download/index.php page and amend it with new release info and links.
* Duplicate the download/windows/index.php page and amend it with new release info (always keeping the "+").
* Create new windows packager script (cloning the current master one and configuring it).
* Copy the xampp_version_head.php file to xampp_version_XY.php.
* Create new windows_wpiXY dir by cloning the previous one (HEAD based), configuring build-latest-XY.sh.
* Edit the stats script, adding the new branch to the versions.
| Integration Lead
|-
| 6.
| style="text-align:center" | ✓
|
| In the Tracker:
* Visit the 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 Add-ons project]. Archive every released version > 6 months old.
* 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). Reindex Tracker. Order them properly on each screen. Hide from all screens the custom fields belonging to 100% unsupported branches.
| Integration Lead
|-
| 7.
| style="text-align:center" | ✓
|
| Add/update the release date, build number and link on the [[Releases|Releases page]].
| Integration Lead
|-
| 8.
| style="text-align:center" | ✓
|
| Post a "git repos updated & tagged" message on the [http://partners.moodle.com/mod/forum/view.php?id=2 Partner forum]
| Integration Lead
|}
===Release===
{| class="nicetable" style="width:100%"
|-
! #
! Major
! Minor
! Task
! style="width:12%" | Responsibility
|-
| 1.
| style="text-align:center" | ✓
|
| 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).
| Integration Lead
|-
| 2.
| style="text-align:center" | ✓
|
| Replace the download/index.php page with its updated counterpart.
| Integration Lead
|-
| 3.
| style="text-align:center" | ✓
|
| Replace the download/windows/index.php page with its updated counterpart.
| Integration Lead
|-
| 4.
| style="text-align:center" | ✓
|
| Notify all registered sys admins, including security notes with CVE identifiers.
| Development Manager
|-
| 5.
| style="text-align:center" | ✓
|
| Post about the release in the [http://moodle.org/news/ moodle.org news]
| Lead Developer
|-
| 5.
| style="text-align:center" | ✓
|
| AMOS needs new "X.Y+1dev" branch to be created, to have master changes performed there.
| AMOS Maintainer
|}
===Post release===
{| class="nicetable" style="width:100%"
{| class="nicetable" style="width:100%"
|-
|-

Revision as of 08:01, 22 May 2013


Six 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. Freeze stable development and post in the General developer forum to inform everyone of the freeze. (example) Development Manager

4 weeks prior

# Major Minor Task Responsibility
1. Review and complete the release notes and upgrading notes of the upcoming version.
  • Ensure all issues labelled with "ui_change" or "api_change" are listed as functional or API changes respectively in the release notes.
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)
  • Make packages available under download.moodle.org (and windows). Promote master up in the download page and adjust info for it.
  • 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).
Integration Lead
3. (Optionally) Announce Beta release in forums (ideally once packages are available). Integration Lead
4. Start QA Community Manager
5. Review documentation for all issues with labels "docs_required", "dev_docs_required" and "qa_test_required", removing this label when relevant docs are updated. Community Manager
6. During the QA weeks integration becomes continuous; release STABLE weeklies normally but master release as often as possible (or on demand). Integration Lead
7. 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

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.1 in the Tracker (MDL and CONTRIB). Integration Lead
3. Clone MDL-39434 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. Merge fixes from en_fix pack and then integrate them. AMOS Maintainer
6. In https://github.com/moodlehq/moodle-behat-extension project:
  • For the new stable version:
    1. Create a MOODLE_XY_STABLE branch from master
    2. Hardcode upstream projects versions in moodle-behat-extension/composer.json according to the latest pulled versions when installing/updating the dependencies to avoid upstream changes breaking stable branches tests
    3. Add a 1.XY.n tag to point to this new branch last commit
    4. Clone MDL-38532, implement, and send it to integration.
  • 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 (integration_held label).
Integration Lead
7. 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
8. Collect security issues into a clone of MDL-39530 to prepare for release of Security Advisories.
  • Determine which security issues will be integrated.
  • Request CVE Identifiers by emailing issue descriptions to distros@vs.openwall.org 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.
  • Post security issues as a reply to the "Heads-up" message on the Partners forum.
Development Manager

Day of release

Packaging

# Major Minor Task Responsibility
1. Make sure there are no real blockers introduced in the last weekly (install / upgrade ...) Integration Lead
2. Verify all unit tests, QA tests and integration tests have passed. Integration Lead
3. Run the mdlrelease process, with the special steps for a Major release.
  • Edit version.php, update release and version to new release values and commit in the integration repository.
  • Tag the integration repository with a tag name vX.Y.0 using "MOODLE_XY" as a tag message.
  • Create the new MOODLE_XY_STABLE branch.
  • Move master to next X.Y+1 version.
  • 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.
  • Push changes to the main Git repo, Github and Gitorious.
Integration Lead
4. Wait for the automated moodle-package to finish building for all versions. Verify the process has ended successfuly (email). Integration Lead
5. In the download server:
  • Duplicate the download/index.php page and amend it with new release info and links.
  • Duplicate the download/windows/index.php page and amend it with new release info (always keeping the "+").
  • Create new windows packager script (cloning the current master one and configuring it).
  • Copy the xampp_version_head.php file to xampp_version_XY.php.
  • Create new windows_wpiXY dir by cloning the previous one (HEAD based), configuring build-latest-XY.sh.
  • Edit the stats script, adding the new branch to the versions.
Integration Lead
6. In the Tracker:
  • Visit the 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 Add-ons project. Archive every released version > 6 months old.
  • 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). Reindex Tracker. Order them properly on each screen. Hide from all screens the custom fields belonging to 100% unsupported branches.
Integration Lead
7. Add/update the release date, build number and link on the Releases page. Integration Lead
8. Post a "git repos updated & tagged" message on the Partner forum Integration Lead

Release

# 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). 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. Development Manager
5. Post about the release in the moodle.org news Lead Developer
5. AMOS needs new "X.Y+1dev" branch to be created, to have master changes performed there. AMOS Maintainer

Post release

# Major Minor Task Responsibility
1. XXX Community Manager
2. XXX Community Manager