Release Management/Beta Release Checklist: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(l10n milestones don't have to be created anymore)
(update of the doc)
Line 30: Line 30:
* Prepare the build from ship-it.  
* Prepare the build from ship-it.  
* Make sure the changeset you're using for the build looks good on treeherder.
* Make sure the changeset you're using for the build looks good on treeherder.
** For desktop, now that we are using [[ReleaseEngineering/Release build promotion|build promotion]], put the long commit number instead of the short one.   You get it like this:
** For desktop, now that we are using [[ReleaseEngineering/Release build promotion|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
***~/dev/mozilla-beta: hg --debug id -r bbaf0ef3deea
***(result:)  bbaf0ef3deea8b2989eb5a23be9861cf3e08720f beta/tip
***(result:)  bbaf0ef3deea8b2989eb5a23be9861cf3e08720f beta/tip
*** Use bbaf0ef3deea8b2989eb5a23be9861cf3e08720f for the changeset in ship-it
*** Use bbaf0ef3deea8b2989eb5a23be9861cf3e08720f for the changeset in ship-it
* Check Tree Status: https://treestatus.mozilla.org/
* Check again the Tree Status: https://treestatus.mozilla.org/
* Start the build from ship-it.  
* Start the build from ship-it.  
* Check for potential issues at the beginning of the build (release runner checks, hg issues, etc)
* 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
* Communicate with QE if they should test anything in particular
* Check QE's results the next day (Sign off emails)
* 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)
* Release your new beta version (If QE signs off, this happens without Release mgmt'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.
* If it's a mobile release, use the mozapkpublisher Python app to manage the upload of the apk
To download the apk, the following should be done:
* Check that the release has been marked as "Shipped" on ship-it (we don't push this button, releng does). https://product-details.mozilla.org/1.0/firefox_versions.json & https://product-details.mozilla.org/1.0/mobile_versions.json should have the correct version of the beta. This is used by the website and other applications.
$ cd mozilla-central.hg/testing/mozharness/scripts
$ python get_apk.py --version 48.0b6 --build 1
Files are going to be downloaded in apk-download/
* update [[https://wiki.mozilla.org/Release_Management/Release_Notes_and_Product_Details#How_to_update_productdetails| 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===
===Set EARLY_BETA_OR_EARLIER===

Revision as of 14:43, 17 January 2017

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.

Mobile What's New Page

A week before beta 1, identify 3 new features that you want to highlight in GP

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 meetings

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

Check approval requests

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
  • Check again the 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 Release mgmt's intervention; for beta 1 and RC, relman should send the "please push" email)
  • If it's a mobile release, use the mozapkpublisher Python app to manage the upload of the apk
  • Check that the release has been marked as "Shipped" on ship-it (we don't push this button, releng does). https://product-details.mozilla.org/1.0/firefox_versions.json & https://product-details.mozilla.org/1.0/mobile_versions.json should have the correct version of the beta. This is used by the website and other applications.

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:

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:

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 (Tuesday or Wed.; the earlier, the more time QE has to test) do the mobile RC build from m-r (We don't push this anywhere)
  • 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.