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

Internal changes

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.

External systems

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.

Odd problems

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

  1. Run the m-r -> m-esrXX no-op trial run:

force-dry-run: true
behavior: release-to-esr
push: true
  1. The diff for esrXX should be fairly similar to this,

  2. Submit a new task with force-dry-run set 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.

Release builds

Make sure to run a staging release.

Update this documentation

Keep this documentation up to date.

Ship it!

Close the bug and have some tea. :)