Release Management/Beta Release Checklist: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(→‎Go to build: fixed the prod details link)
m (→‎Set EARLY_BETA_OR_EARLIER: clarify null...heh)
Line 30: Line 30:
We change a flag for Beta 4 (usually).  
We change a flag for Beta 4 (usually).  
* [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Source_Code/Mercurial Check out] the [https://hg.mozilla.org/releases/mozilla-beta/ mozilla-beta] repo (this takes over an hour, the first time)
* [https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Source_Code/Mercurial Check out] the [https://hg.mozilla.org/releases/mozilla-beta/ mozilla-beta] repo (this takes over an hour, the first time)
* change the build/defines.sh file to read EARLY_BETA_OR_EARLIER= (unset the flag, from 1 to null)
* change the build/defines.sh file to read EARLY_BETA_OR_EARLIER= (unset the flag, from 1 to null) (nothing at all after the =)
* commit locally with a useful commit message like this, "Post Beta 4: disable EARLY_BETA_OR_EARLIER a=me"   
* commit locally with a useful commit message like this, "Post Beta 4: disable EARLY_BETA_OR_EARLIER a=me"   
* [https://hg.mozilla.org/releases/mozilla-beta/rev/49e75ecb84f8 push your change directly] to mozilla-beta (An exception to the usual [[Tree Rules]]
* [https://hg.mozilla.org/releases/mozilla-beta/rev/49e75ecb84f8 push your change directly] to mozilla-beta (An exception to the usual [[Tree Rules]]

Revision as of 18:40, 1 September 2015

Draft for a beta release checklist.


Update the calendar

Usually we ship beta 1 at the beginning of the week, then in the second week to the fifth week, ship two betas per week. The last week will be the Release Candidate (RC) version and should be on beta for the week before release.

Check worry list

Use a worry list etherpad to keep track of bugs that should land before each beta cycle and the status of new features. This could be especially useful for handoff to other release managers.

Prep for channel meeting

The release manager who owns the current beta usually runs the channel meeting.

Check approval requests

Good to do these in small batches every day.

Go to build

  • Prepare for starting the build by going through approvals the night before.
  • Check treeherder to make sure the changeset you want to use looks good. Talk with the sheriffs if you need them to merge more changes. From the time of the merge, treeherder needs at least 3 hours to complete all its tests.
  • Prepare the build from ship-it.
  • Make sure the changeset you're using for the build looks good on treeherder.
  • Make sure to create a new l10n milestone for each beta build.
  • Check Tree Status: https://treestatus.mozilla.org/
  • Start the build from ship-it.
  • Communicate with QE if they should test anything in particular
  • Check QE's results the next day
  • Release your new beta version (If QE signs off, this happens without RelMan's intervention)
  • update [product details]
  • add release notes

Set EARLY_BETA_OR_EARLIER

We change a flag for Beta 4 (usually).

  • Check out the mozilla-beta repo (this takes over an hour, the first time)
  • change the build/defines.sh file to read EARLY_BETA_OR_EARLIER= (unset the flag, from 1 to null) (nothing at all after the =)
  • commit locally with a useful commit message like this, "Post Beta 4: disable EARLY_BETA_OR_EARLIER a=me"
  • push your change directly to mozilla-beta (An exception to the usual Tree Rules

Update PRODUCT DETAILS

Retrieved from "https://wiki.mozilla.org/index.php?title=Release_Management/Beta_Release_Checklist&oldid=1093262"