Release Management/Beta Release Checklist

From MozillaWiki
< Release Management
Revision as of 15:48, 19 November 2015 by Lizhenry (talk | contribs) (→‎Go to build: added reminder to email after play store push)
Jump to navigation Jump to search

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 for Desktop, one for Mobile. The last week will be the Release Candidate (RC) version (Desktop only) and should be on beta for the week before release.

Check worry list

Use a worry list 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.
  • Consider stabilizing the risky beta patches over Nightly and Aurora channels.

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.
  • Check for potential issues at the beginning of the build (release runner checks, hg issues, etc)
  • Communicate with QE if they should test anything in particular
  • Check QE's results the next day (Sign off emails)
  • Release your new beta version (If QE signs off, this happens without RelMan's intervention; for beta 1 and RC, relman should send the "please push" email)
  • If it's a mobile release, download apks, upload to Play store, email r-d that the mobile version was pushed.
  • update [product details]
  • Check that the release has been marked as "Shipped" on ship-it

Set EARLY_BETA_OR_EARLIER

We change a flag after 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 =) The process is documented in the Release calendar.
  • push your change directly to mozilla-beta (An exception to the usual Tree Rules
  • So, Beta 4 is still early beta. Beta 5 is "after early beta".

Check what's new page

At Beta 4 this may be a good time to make sure releng is aware of any upcoming What's New pages. This should be already managed in a bug and localizers should have been aware earlier in the release cycle. Examples:

MailTo: release@m.c (RelEng team) to communicate the final decision on whether a What's New Page is planned or not.

Update PRODUCT DETAILS

  • More details at wiki page: Product Details
  • You can't currently update product details for RC builds.

Other activities

  • Regular follow up on tracked bugs with the following intentions:
    • Look for bugs that are fixed in Nightly/Aurora and ping devs to nominate for uplift to Beta
    • Look for bugs that haven't had much activity for a while and work with devs to find owners to fix.

RC builds

At the end of the beta cycle we do a release candidate or RC build. Relman does the final email to push the RC build live after QE signoff, as with beta 1. (While QE does the signoff alone for the other beta releases).

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