Release Days

From MozillaWiki
Jump to: navigation, search


Release Day

Previous day

  • Wait for QA to sign off QA signs off for Firefox 131
  • Send an email to r-d asking to push the file to the CDN
Subject: [desktop] Please push Firefox 131.0 (build#X) to the release-cdntest channel
To: r-d

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
  • Also join #release-coordination on slack
  • 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 131.0 (build #X) - 10% staged roll out
To: r-d

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

{YOUR NAME}

In the past, uploads were done by hand by release manager (or with mozapkpublisher). If a different update percentage is needed, a release manager will have to log in to the Google play interface and change it.

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

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

{YOUR NAME}


  • RelEng automation will automatically publish the updates, RelEng will announce to release-drivers.
  • Switch the release notes to public in Nucleus
    • Confirm that the security release note has been added
    • Confirm that the known issues from the previous release are either marked as fixed or carried over
    • Confirm that the new Mozillian thank you note has been added
  • Release owner (from relman team) will push security advisories live.
  • Once releng has marked the release as shipped, check that the correct versions appear here: https://product-details.mozilla.org/1.0/firefox_versions.json & https://product-details.mozilla.org/1.0/mobile_versions.json
  • Since version 56, the Mozilla.org website should have the correct version as soon as updates are live.


  • QA sign-off on updates for Desktop
  • Let PMM (communications@mozilla.com) know they can push blog posts and start communicating to Press
  • 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 131 is now available
To: announce@lists.mozilla.org

Firefox 131 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 60 Released
To: enterprise@mozilla.org

Firefox ESR 60 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 60 are available at:
https://www.mozilla.org/en-US/firefox/60/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 131.
  • 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 :

  • Check availability, heads up to key staff from QA, relman, releng, sec team
  • Check ops page for planned maintenance to infrastructure https://mozilla2.statuspage.io/ Talk with ops staff from #moc privately if needed
  • Ask for sec advisory draft if needed
  • 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
  • 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