|
|
| Line 1: |
Line 1: |
| {{Release:DocMainHeader}}
| | Deprecated in favour of Release Promotion. See https://github.com/mozilla/releasewarrior. |
| | |
| After we get a "go to build" e-mail from Release Management there's some manual steps to be run to prepare for and start a release. This page describes them in detail.
| |
| | |
| = Overall beta release =
| |
| [[File:Beta-release-schema.png]]
| |
| | |
| Source: [[File:Beta-cycle.zip]]
| |
| | |
| See also: | |
| * [http://moz-releng-docs.readthedocs.org/en/latest/release_workflows/fx_ga_release.html GA Workflow] (used for both GA and first Beta builds).
| |
| * [http://moz-releng-docs.readthedocs.org/en/latest/release_workflows/fx_beta_release.html Beta Workflow] (used for remaining beta releases)
| |
| | |
| = Submit to Ship It =
| |
| <b>''This task is completed by Release Management''</b>
| |
| | |
| Releases are initiated through the [https://ship-it.mozilla.org/ Ship It webapp] (through the Mozilla VPN). When you're ready to start a release, you can use the [https://ship-it.mozilla.org/submit_release.html "Submit a new release" page] to submit it. Once it's in the system you should find '''someone else''' to review it for you. They can see it and mark it as ready on [https://ship-it.mozilla.org/releases.html the "View releases" page]. If multiple releases are expected around the same time it's often best to wait until all are ready for review, so that they can be started at the same time.
| |
| | |
| Track Ship-It status on the [https://ship-it.mozilla.org/releases.html the "View releases" page]. If there are errors reported, check your email for details from "<tt>cltbld</tt>" with subject starting "<tt>[release-runner]</tt>".
| |
| | |
| == Defaults ==
| |
| Unless otherwise stated by RelMan we stick to certain assumptions about releases:
| |
| * Firefox betas need partial updates from the previous 2 betas
| |
| * Firefox releases (that is, a release on the release channel) need partial updates from the 3 past versions with the most users. If you don't know how to get this information ask someone in RelEng or RelMan.
| |
| * A "go" for Firefox implies a "go" for Fennec, too
| |
| | |
| = Paperwork =
| |
| A release specific bug should be filed, except for b2 to bN (end of cycle). releaseduty is on the hook to pre-file these, but it should be done manually for chemspills. These bugs should:
| |
| * be assigned to the releng person handling the release
| |
| * ensure the relman lead is cc'd (since they start the build, and need to be aware of any infrastructure blockers)
| |
| | |
| [[Releases/BuildNotesIndex|Build notes]] are required for every release, located at Releases/<app>_<version>/BuildNotes (eg [[Releases/Firefox_34.0b4/BuildNotes]], [[Releases/Firefox_33.0.2/BuildNotes]], [[Releases/Thunderbird_31.2.0/BuildNotes]]). A copy of the [[Releases/RelEngChecklist | Checklist]] should be copied in, so that work items can be marked off as they are completed. This makes handing-off releases between people more reliable.
| |
| | |
| File bugs on specific issues you hit which can be fixed by automation improvements, or for patches that require review and there is no release tracking bug.
| |
| | |
| [[category:Release_Management|R]]
| |