Release Management/Release Days

From MozillaWiki
Jump to: navigation, search

Release Day

Previous day

  • Wait for QA to sign off QA signs off for Firefox 55
  • Send an email to r-d asking to push the file to the CDN
Subject: [desktop] Please push Firefox 55.0 (build#X) to the release-cdntest channel
To: r-d
  • QA should sign-off channel updates
  • Release notes signed off
  • File a bug under BMO:Administration asking for new version's bugzilla flags (status, tracking). Don't forget new ESR flags when major releases come out.

About merge day

Release day

  • Join #www, #releng, #release-drivers, #planning and #releaseduty to make sure people can contact you and you can ask questions or ping people
  • Send instructions to r-d to upload Firefox for Android with a staged roll out to 10% (around 7 PST):
Subject: [mobile] Please upload Firefox Android / Fennec 55.0 (build #X) - 10% staged roll out
To: r-d

Please upload Firefox Android / Fennec 55 (build #X) - 10% update rate.

{YOUR NAME}
  • Then for Desktop
Subject: [desktop] Please push Firefox for Desktop 55.0 (build #X) to the release channel - 25% update rate (24h)
To: r-d

Please upload Firefox for Desktop / 55 (build #X) - 25% update rate for 24 hours

{YOUR NAME}

In the past, uploads were done by hand by release manager (or with mozapkpublisher).

Please upload to Yandex too.

  • RelEng automation will automatically publish the updates, RelEng will announce to release-drivers.

This is necessary to see the correct downloads on the mozilla website.


  • QA sign-off on updates for Desktop
  • Let PMM (communications@mozilla.com) know they can push blog posts and start communicating to Press
  • Let security know that they can push their security advisories
  • Update Releases#Previous_Releases
  • Send announcement of new release to announce@lists.mozilla.org:
    • Note: You will need to approve your post to this list in the admin interface
Subject: Firefox 55 is now available
To: announce@lists.mozilla.org

Firefox 55 is now available as a free download for Windows, Mac OS X, GNU/Linux, and Android from http://www.mozilla.org/firefox/new/.

We recommend that users keep up to date with the newest version of Firefox for the latest features and fixes.

This release contains {FOR MAJOR RELEASE, TRY TO LIST 3 ITEMS FROM RELNOTES | FOR MINOR RELEASE, TRY TO SUMMARIZE LIKE "security and stability fixes"}

The release notes for this release are available at:
Desktop: http://www.mozilla.org/firefox/notes
Mobile: http://www.mozilla.org/mobile/notes
 
{YOUR NAME}
Firefox Release Manager


  • Once an ESR is released, you can push
Subject: Firefox ESR 52 Released
To: enterprise@mozilla.org

Firefox ESR 52 is now available for download at https://www.mozilla.org/en-US/firefox/organizations/all.html. 

As always, we recommend that users keep up to date with the newest version of Firefox ESR for the latest stability and security fixes.

Release notes for Firefox 52 are available at:
https://www.mozilla.org/en-US/firefox/52/releasenotes/

Associated security advisories will be posted once available at:
https://www.mozilla.org/security/known-vulnerabilities/firefoxESR.html

{YOUR NAME}
Firefox Release Manager

The day after

  • Releng tooling will disable updates automatically after 24 hours. Make sure that you received the email notifying this.

If you want to turn off or moderate manual updates as well as background updates, instead ask:

Please disable updates for Firefox 55.
  • For Desktop, send an email to r-d to turn on updates when confident that no dot releases will be mandatory

Dot releases and chemspills

In a "chemspill" situation we release on whichever channels necessary, with only the necessary patch(es), as fast as possible. This is usually reserved for situations where a critical security exploit is public.

Taking other patches increases the risk of delay (since tests or builds may fail, or manual testing may find new problems).

For a "dot release" we may need to release on multiple versions. Or, we may need only a Fennec or Desktop version and not both. If, after that, we need a new dot release, it is best to keep the numbers consistent if the Gecko version is the same, rather than having the numbering "out of sync".

The product team has requested that we serve what's new pages (WNP) to desktop users for the first dot release after a major release (so, users will see the WNP twice during a cycle) as of Firefox 55.

Since you will likely be handling from 3 to 5 simultaneous releases, it helps even more than usual to have a checklist for each one, using a table or spreadsheet to track each step for each channel.

Example items for checklist for 53.0.2 dot release :

  • List patches that need to land
  • All patches have landed
  • Write release notes
  • Tests and builds are ok on treeherder
  • Start build from ship-it
  • Ask for sec advisory draft if needed
  • Releng notice that builds completed
  • QE signoff, manual testing
  • Release-localtest update tests
  • Send email to push to cdntest
    • * If there's a What's New Page for desktop, remind releng (in the push request)
  • Releng response
  • cdntest update tests
  • Send email to push live
  • Releng response
  • Adjust rollout % for fennec if needed
  • Set relnotes public
  • Make sure sec advisories are live