Mozilla considers switching to a 9 week release schedule
When Mozilla announced that it would change the Firefox release model to one that it called Rapid Release Model, it was seen by part of the browser's user base to compete with the Google Chrome browser which outpaced Firefox release wide.
Not all users liked the new model with its new releases every six weeks, and the Extended Support Release (ESR) was introduced by Mozilla to give all who could not or did not want to keep up with an alternative.
The current release cycle has a length of 18 weeks from the first day a Nightly build is created to the day it is released as a stable build. Builds are kept for six weeks in the Nightly channel before they are moved to the Aurora channel where they stay another six weeks. The build is then moved to the Beta channel and after six weeks of staying there is released to the public as the new final version of Firefox.
It takes 18 weeks of development to create a new Firefox version, with new stable builds being released every six weeks to the public.
Mozilla is contemplating a change in the release schedule that won't have the same wide-ranging impact that the Rapid Release Model had. The idea is to stay true to the 18 week development cycle but change how long builds are kept in the different channels.
The major change here is a move to a 9 week release schedule without changing the 18 weeks of development. The development time of the Nightly versions of Firefox is increased to nine weeks, with the Aurora and Beta channels sharing the other nine weeks.
After nine weeks of Nightly development the build is moved to the Aurora channel where it stays for one or two weeks before it is moved to Beta. Development in Aurora continues alongside for the remainder of the nine week period, and new or experimental features may be added to the build that are not added to the Beta channel.
Sounds confusing? All that changes if the Coupled Train Model is implemented are the intervals that builds are kept in Firefox's release channels.
- Stable users: New major versions of Firefox get released in a nine week cycle instead of the current six week cycle.
- Beta users: Will get new releases earlier than before. Instead of having to wait 12 weeks before new versions hit the channel, it will now take between 10 and 11 weeks.
- Aurora users: Same changes as for stable users, new versions hit after nine weeks instead of six.
- Nightly users: A nine week development cycle instead of the current six.
So what is the motivation behind the proposed change? The idea to "get new code in front of the most users as soon as possible". When releases are moved to the Aurora channel currently, it usually takes only a week to find major issues and beta-blocking issues. This means that there is little reason to not move the release to the Beta channel afterwards, so that it is exposed to a greater number of users.
Things still need consideration, like a start date for the proposed switch (maybe Firefox 30), a new string and API freeze date, the frequency of security updates, or how the ESR channel is affected by this. As far as the ESR channel is concerned, options are to either extend it by 21 weeks (7x3) or reduce the number of cycles it goes through to keep the current release interval. (via Sören)
Advertisement
Its getting more attention:
https://groups.google.com/forum/#!topic/mozilla.dev.planning/x17zOBsQMsY
Interesting, thanks for posting.
I wonder if the Aurora/Beta overlap might be more trouble than it’s worth.
Maybe it’s not a big pain to have to land every code change twice, but I’d be concerned about mistakes and oversights.
Personally, I’m still on the I’ll-update-when-I’m-damn-good-and-ready schedule (which I’m typing to you now using Fx19).
You should update to 24, it’s a lot better than 19 provided you have no addons that break, or just wait until 25 comes out which shouldn’t be long.
I would welcome it, the only bad thing would be security updates would be pushed back 3 weeks later than normal.
Critical updates are still released out of schedule, so that this should not be a big issue.