A job, called
l10n-bumper, runs on Taskcluster every hour, and stores information on the l10n changesets to use for each build in a file called
- For Nightly (
mozilla-central), l10n-changesets.json always uses the revision
default, and it’s only updated when changing the locales available in the build.
- Beta builds (
mozilla-beta) still use the tip of the l10n repository, but the actual hash is stored in l10n-changesets.json instead of
- Before Release Candidate week, the
l10n-bumperis manually stopped on
mozilla-beta. Since the configuration change lands only on
l10n-bumperwill automatically restart at the beginning of the next cycle, when the standard configuration is uplifted from
- When the Beta code is merged to Release, l10n-changesets.json moves together with the rest of the code to
mozilla-release. That means that Release builds will use the same changesets as the last beta with the same version number, and any further change requires code uplifts.
This is how Beta looks like in a 4 weeks release cycle, with relevant milestones.
On Monday, 8 days before the release, the
l10n-bumper will stop updating
Once the code merges from Beta to Release, any changeset update would require a manual uplift to
mozilla-release and a new Release Candidate (RC) build.
When the code moves from
l10n-changesets.json is frozen, as
l10n-bumper is not configured to run against the release branch.
In case of severe issues affecting one or more locales, it’s still possible to manually update the shipping changesets. A patch needs to be provided for
mozilla-release branch and approved for uplift by Release Drivers (see for example this bug and associated patch). Note that a dot release is needed in order to ship the updated version to users.
The same process applies to ESR versions, as long as the associated esr repository is included in the current version of cross-channel.