Release:Release Automation on Mercurial:Starting a Release - Revision history

Bhearsum at 18:23, 2 June 2017

2017-06-02T18:23:42Z

← Older revision		Revision as of 18:23, 2 June 2017
Line 1:		Line 1:
	~~Deprecated~~ in ~~favour of~~ Release ~~Promotion~~. ~~See~~ https://~~github~~.~~com~~/mozilla/~~releasewarrior~~.		{{Release:DocMainHeader}}

			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]]

Bhearsum: Replaced content with "Deprecated in favour of Release Promotion. See https://github.com/mozilla/releasewarrior."

2017-05-30T18:59:58Z

Replaced content with "Deprecated in favour of Release Promotion. See https://github.com/mozilla/releasewarrior."

← Older revision		Revision as of 18:59, 30 May 2017
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]]~~

Sylvestre: remove l10n stuff \o/

2017-01-17T15:07:06Z

remove l10n stuff \o/

@@ Line 11: / Line 11: @@
 * [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 =

Lizhenry: /* Create milestones */ note on RC milestones

2015-09-15T16:20:37Z

Create milestones: note on RC milestones

← Older revision		Revision as of 16:20, 15 September 2015
Line 25:		Line 25:
	* click the checkbox(es) for the product(s) you want to bump.		* click the checkbox(es) for the product(s) you want to bump.
	** For betas, make sure the beta # in both fields matches the one you're doing (eg "Beta Build 4" == "Beta 4")		** For betas, make sure the beta # in both fields matches the one you're doing (eg "Beta Build 4" == "Beta 4")
	** For '''final releases''' clear the first field, remove "_beta_b#" from the second field, and append ".0" (or .0.1).		** For '''final releases''' (including RC) clear the first field, remove "_beta_b#" from the second field, and append ".0" (or .0.1).
	* hit "submit" and the milestones will be created.		* hit "submit" and the milestones will be created.

Bhearsum at 16:45, 19 August 2015

2015-08-19T16:45:58Z

← Older revision		Revision as of 16:45, 19 August 2015
Line 72:		Line 72:
	* 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.		* 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		* A "go" for Firefox implies a "go" for Fennec, too

	~~== How to review a release ==~~
	~~Here's a list of things we normally look for when reviewing release submissions:~~
	* Version, build number, branch, and changesets match what was given in the "go" e-mail.
	* Relbranch is absent unless specified in the go.
	* Partial versions are from recent releases and using the same build number that was shipped for that version.
	* Dashboard check is enabled for betas, disabled for release/esr.
	* L10n changesets match the same format as the previous release and roughly the same number of entries

	= Paperwork =		= Paperwork =

Hwine: link to workflow diagrams

2015-08-18T22:19:45Z

link to workflow diagrams

← Older revision		Revision as of 22:19, 18 August 2015
Line 7:		Line 7:

	Source: [[File:Beta-cycle.zip]]		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)

	= L10N Changesets =		= L10N Changesets =

Hwine: add link to build notes index

2015-08-18T22:03:26Z

add link to build notes index

← Older revision		Revision as of 22:03, 18 August 2015
Line 82:		Line 82:
	* ensure the relman lead is cc'd (since they start the build, and need to be aware of any infrastructure blockers)		* ensure the relman lead is cc'd (since they start the build, and need to be aware of any infrastructure blockers)

	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.		[[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.		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]]		[[category:Release_Management\|R]]

Hwine: relman needs to be cc'd

2015-05-04T00:15:36Z

relman needs to be cc'd

← Older revision		Revision as of 00:15, 4 May 2015
Line 78:		Line 78:

	= Paperwork =		= 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.		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)

	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.		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.

NThomas: /* Paperwork */ make app agnostic

2014-10-28T20:44:31Z

Paperwork: make app agnostic

← Older revision		Revision as of 20:44, 28 October 2014
Line 80:		Line 80:
	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.		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.

	Build notes are required for every release, located at Releases/~~Firefox_~~<version>/BuildNotes (eg [[Releases/Firefox_34.0b4/BuildNotes]], [[Releases/Firefox_33.0.2/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.		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.		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]]		[[category:Release_Management\|R]]

NThomas: /* Paperwork */ Process changes for notes and checklist

2014-10-28T20:41:40Z

Paperwork: Process changes for notes and checklist

← Older revision		Revision as of 20:41, 28 October 2014
Line 78:		Line 78:

	= Paperwork =		= Paperwork =
	A release specific bug should be filed, except for b2 to bN (end of cycle). ~~Rail Aliiev~~ is on the hook to pre-file these ~~(and also assign releases to people)~~, but it should be done manually for chemspills.		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.

	~~For b2 to bN, build~~ notes are ~~not~~ required, ~~unless something goes wrong~~. ~~If something does go wrong you must:~~		Build notes are required for every release, located at Releases/Firefox_<version>/BuildNotes (eg [[Releases/Firefox_34.0b4/BuildNotes]], [[Releases/Firefox_33.0.2/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.
	* Create build notes, ~~and take notes on what went wrong +~~ the ~~fix~~
	* File ~~a bug~~ on ~~the~~ specific ~~issue~~ you hit~~. (Eg: "updates failed~~ for 23.~~0b5")~~		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]]		[[category:Release_Management\|R]]