Merge Duty for major ESR bump
Merge Duty for major ESR bump#
This manual describes how to set up a new ESR branch. The same process can be applied for any branch set up, with slight modifications.
Example tracking bug: Bug 1717527 - tracking bug for build and release of Firefox 91.0esr
For in-tree changes, grepping for the old esrXX (e.g. on searchfox) should be a good starting point to figure out the necessary updates. It can also be useful to compare with the changes from the previous ESR bump.
Before the new build, rules should also be set up in balrog (stage and production): - a rule with alias firefox-esrXX-localtest on the esr-localtest* channel - a rule with alias firefox-esrXX-cdntest on the esr-cdntest* channel - a rule with alias esrXX on the esr channel
The rules can initially point at the No-Update mapping and are then updated by automation. Rules on the esr-localtest-next and esr-cdntest-next channels should be adjusted so that updates to the new ESR are served (sometimes with a watershed on the previous ESR, depending on app requirements; otherwise the rules for the previous ESR can be changed to no longer apply to the -next channels). Each esrXX rule’s Version field should be set to <XY.0 where XY == XX+1.
Before the first release from the new ESR branch, the release-bouncer-aliases task on the previous ESR branch needs to be updated to not touch the firefox-esr-next-* aliases, to avoid issues like bug 1786507.
CI relies on multiple systems, supported by different teams. File bugs in advance to make sure other teams have enough time to address the issue. Usually starting the whole process 2 weeks in advance of release builds (3 weeks before the release), gives enough time to everybody.
for the tracking bug look at each bug in the tree and see if it is needed in the next ESR. Most likely it will be.
The old esr branch needs to be updated to stop setting the esr-next-latest bouncer aliases before the first release from the new branch, e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1791744.
- mozilla-version needed an update.
remember to push shipit changes that contain mozilla-version update to production branch, don’t leave on master only
remember to update treescript
remember to merge scriptworker-script (treescript) changes to production and let the ci-change bot complete
UVNEXT* tasks (update verify next) will fail (run in promote phase) unless proper balrog (esr-localtest-next) rule exists
Merge release to esr#
m-r -> m-esrXXno-op trial run:
force-dry-run: true behavior: release-to-esr push: true
The diff for
esrXXshould be fairly similar to this,
Submit a new task with
force-dry-runset to false:
force-dry-run: false behavior: release-to-esr push: true
It’s not unlikely for the push to take between 10-20 minutes to complete.
Make sure to run a staging release.
Update this documentation#
Keep this documentation up to date.
Close the bug and have some tea. :)