Firefox devs propose accelerated schedule
It's (all) about time
Firefox 4 is coming out tomorrow, and I'm looking forward to using it on my Linux machines and the lone Windows machine I keep around the house.
This release has been a long time in coming, and has been delayed by four or five months, depending on whose original release estimate you use. Firefox 4 development was marked by umpteen beta releases and, even this past weekend, they snuck out a second release candidate, just days before the gold release on March 22.
Meanwhile Internet Explorer 9 is out, stealing some of Firefox's thunder, at least on Windows. While Firefox fans ultimately won't care one whit about IE 9, it does hurt Firefox perception from non-Firefox users who might switch over (and there are still plenty of such users out there).
In order to prevent this big-yet-late release cycle from happening again, one Mozilla developer has proposed a much faster cycle, with as little as 16 weeks between major point releases.
That means a Firefox 5 and 6 release for 2011, for sure with 7, 8, and 9 geared up for 2012.
Rob Sayre, the author of the plan, wants to decrease Firefox release development by creating different channels for new features to be added into the release cycle.
The four channels in the process, tentatively labeled "mozilla-central (or 'nightly'), firefox-experimental, firefox-beta, and Firefox (release)," will provide the path to release. As new features are added to the nightly build, they will be refined and ideally promoted to the experimental channel. If a new feature is not ready, it will stay in the mozilla-central channel until it is deemed ready to start heading towards release.
"Each release channel is backed by a Mercurial repository containing a distinct copy of the Firefox source code.As a set of changes progresses through the repositories, features that aren't quite ready are disabled. New features are never directly added to the firefox-experimental or firefox-beta channels. Features that end up disabled or miss the scheduled transition to the experimental channel can be pulled again the next time the schedule permits. This policy does allow for features that take a long time to develop. It's just that they'll be present only on mozilla-central until they're ready. The number of users on each channel grows by roughly 10x as the changes make their way through the release process, and features on each channel require an accompanying improvement in stability," Sayre writes.
Doing it this way, Sayre argues, will prevent new features from holding up the next release of Firefox. If they are too unstable, the new feature simply stays in the nightly build channel until developers there can get it to work.
Of course, as features are promoted up to the next channel, there's the possibility that something might break as a result of the new code.
"The first few days after code arrives on a channel are spent turning features off, backing out patches that cause stability problems, etc. There will be many judgement calls concerning whether it's possible to save a feature with a few spot fixes. As Mozilla gains experience with this process, more concrete policies will emerge. The reason this work happens after new code appears on a channel is so that work can continue uninterrupted in the other repositories," Sayre outlines. "If a feature needs to be turned off on a release channel, it's the developer's responsibility to make a patch to do so. If a feature can't be disabled without turning off or backing out other things, then those other things will also get turned off or backed out."
It's an ambitious plan, and if properly implemented, should prevent the delayed year-long release cycle we have seen for Firefox 4. Sayre proposes creating the new experimental and beta channels and seeing them with about a half million users on the experimental channel and 1.5 million on the beta channel.
This will also change the way security updates happen in Firefox.
"This proposal makes security updates occur along with Firefox releases, meaning we'll no longer be maintaining old branches. Having security branches for each major update is untenable if we release as often as we aim to," Sayre explains.
So now it's a question of whether this proposal will be accepted and implemented for Firefox 5. I'm no developer, but it feels like this sort of release cycle would be an improvement over what's happening now. Actual developers, of course, may have a differing opinion.