User:Bhearsum/Release Days
Contents
Release Day
Previous day
- Wait for QA to sign off QA signs off for Firefox 132
- Send an email to r-d asking to push the file to the CDN
Subject: [desktop] Please push Firefox 132.0 (build#X) to the release-cdntest channel To: r-d
- QA should signoff on cdntest channel updates.
- Release notes signed off
- Signoff on Scheduled Change in Balrog.
- 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.
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
- Upload mobile APKs using Staged Rollout (starting at 10%) (around 6 PST, due to the Google play latency)
using https://github.com/mozilla-releng/mozapkpublisher/ (should be managed by Releng in the future)
python mozapkpublisher/push_apk.py --package-name org.mozilla.firefox --track rollout --rollout-percentage 10 --service-account xxxxxxx --credentials yyyy --apk-x86=apk-download/fennec-132.0.multi.android-i386.apk --apk-armv7-v15=apk-download/fennec-132.0.multi.android-arm-api-15.apk
Send a notification to r-d to inform them of the upload
- RelEng automation will automatically publish the updates, RelEng will announce to release-drivers.
- If the release should not be published, revoke your signoff from the Scheduled Change in Balrog.
- 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
- Formerly we updated the product-details svn repo by hand with beta and release versions and dates. Now that happens automatically from ship-it and the resulting files are here: https://product-details.mozilla.org/1.0/
- Check the results:
- 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 132 is now available To: announce@lists.mozilla.org Firefox 132 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 132.
- For Fennec, if there are no critical issues after 48 hours, please change Play Store staged rollout rate from 10% to 100%. See steps at Increase your staged rollout percentage
- 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".
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
