David Baron's Weblog

Fifteen years

A possible approach to shorter release cycles

Thursday, 2014-11-06, 14:12 -0800

One of the problems we've been facing with Mozilla's release cycle is that it takes a relatively long time for code to get from commit to the mozilla-central repository to get into the hands of our users. It's currently 12-18 weeks, because the current process has four repositories (central, aurora, beta, release) with most code landing on central, and with code shifting from one repository to the next every six weeks, and shipping to Firefox release users when it reaches the release repository:

[Diagram showing
flow of code across nightly, aurora, beta, and release repositories,
with movement from one to the next every six weeks, and channel
populations corresponding to each repository]

In addition to being slower than we'd like, we're not getting quite as much feedback as we'd like since the population of aurora users is relatively small and have habits much more similar to our nightly users than our release users. This means that we don't get feedback about many real-world problems until code reaches the beta channel.

One alternative that's been discussed a few times is to have one fewer channel. People have brought up some drawbacks with that approach, such as that code pulled from mozilla-central the previous day isn't necessarily ready to be shipped to large population of users on the beta channel.

To address that, I'd like to propose an alternative that shortens the path by six weeks (and removes one of the four repository stages), but keeps the four separate populations:

[Diagram
showing revised structure with three repositories, differing from
current behavior by placing the beta user population on the release
repository for the first part of the cycle but then on the aurora
repository for the bulk of the cycle]

This model differs from what we do now by eliminating the mozilla-beta repository, and thus removing six weeks from the cycle. Users on the nightly, aurora, and release channels would get code like they do now, tied to one repository. Users on the beta channel, however, could get code from the release repository for the first week or so of the cycle (right after we ship that release), and then get code from the aurora repository (which will become the next release) for the rest of the cycle. In other words, users on the beta channel won't change the version that they're running on merge day, but instead a week (or maybe two) later.

Having the beta users switch repositories has two advantages. First, it means that beta users will be able to beta-test any point releases that we ship in the first week or so of the cycle. Second, it means that we'll have a week or so to fix any serious stability problems in the aurora repository before updating all beta users to it.

To be clear, this is just my proposal for what I think we could do, not something that anyone is already planning to do. But I think it could be a good way to get us a faster release cycle that would allow us to get our work faster into our users' browsers.