Release Management/Beta Release Checklist

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.
  • For desktop, now that we are using build promotion, put the long commit number instead of the short one. You get it like this:
    • ~/dev/mozilla-beta: hg --debug id -r bbaf0ef3deea
    • (result:) bbaf0ef3deea8b2989eb5a23be9861cf3e08720f beta/tip
    • Use bbaf0ef3deea8b2989eb5a23be9861cf3e08720f for the changeset in ship-it
• 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 (we don't push this button, releng does)

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 about NSS

• good idea to check in around mid beta with someone who works on nss to see if they are planning an update, and if it needs to also be in ESR. Canonical list of NSS versions shipped in which Firefox versions: https://kuix.de/mozilla/versions/

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:

• 34 https://bugzilla.mozilla.org/show_bug.cgi?id=1102419
• 42 https://bugzilla.mozilla.org/show_bug.cgi?id=1196518

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.

Check downloads page

While QE signs off for update testing, you may also want to:

• Check that Beta updates and opens on your android device and desktop version
• Check the download pages
  • Beta: https://www.mozilla.org/en-US/firefox/channel/
  • All locales, mobile: https://www.mozilla.org/en-US/firefox/android/beta/all/
  • All locales, desktop: https://www.mozilla.org/en-US/firefox/beta/all/

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).
  • anything you uplift after the beta to release migration, make sure it lands on both m-b and m-r
  • Build fennec (10 or 12) from mozilla-beta. Upload to play store beta as usual
  • Build desktop RC from mozilla-release (and push it to the beta channel)
  • We don't update product details for (desktop) RCs
  • The partial builds for RC1 should be the 2 previous releases with the highest ADI (but choose >= version 43 due to sha-1 deprecation), plus the latest beta. For example, for 44.0, partial builds were: 43.0.4build3, 41.0.2build2, 42.0build2, 44.0b9build1. (Using 4 partials overloaded taskcluster)
  • Subsequent RCs: ??
• Later in the week (Wed. or Thurs) do the mobile RC build from m-r (I think we don't push this to beta? Or do we.)
• You will need to hand-edit the l10n milestone name as described here: https://wiki.mozilla.org/Release:Release_Automation_on_Mercurial:Starting_a_Release
• We list the beta 10 for fennec in mobileHistory and mobile_beta_version in product details, but not the desktop RC.