Previously, early in the morning the build system blindly updated to the latest tip of tree, built it, generated updates, and made them available on the proper channel–even if there were no changes since the last time. This was inefficient for users, a poor use of build system resources, and unnecessarily contributed to update fatigue for less-active channels.
The new behavior makes it so automated morning builds only occur when the code or dependent localizations have actually changed since the last update.
What this means to you
This is how the new behavior affects you if you are on the following channels:
This has no impact on the Release channel. You will continue to see updates to the latest supported version of Firefox every 6 weeks.
This has no impact on the Beta channel. You will continue to see updates to the latest supported beta of Firefox every week.
This change will likely make it so updates are less frequent. Towards the end of the 6 week Aurora period there are considerably less changes being landed into mozilla-aurora by design. Updates offered on the Aurora channel during that time should be less frequent as well.
While the automation change also applies to the mozilla-central repository, there is a lot of activity there every day. We don’t expect to skip an update due to inactivity.
Older releases / project branches
Developers on project project repos (like UX, places, rentable repos) and older branches (like mozilla-1.9.2) should see the most benefits. These repositories typically go weeks without any activity and thus will see the greatest update churn reduction.
This behavior change was specifically asked for when we designed the new rapid release process. It is great to see Release Engineering roll it out in a timely manner without any hiccups. The speed of the fix and minimal developer disruption is a testament to the build system and the team that maintains it. Thanks for the hard work!