Firefox 4.0 has been delayed a number of times, but looks to finally be
on the verge of release. With 4.0 out the door, the Mozilla developers will be pursuing a quarterly release cycle that would see Firefox 5, 6, and 7 released by the end of 2011. For Windows and Mac users, accelerated releases just mean they'll see more frequent updates. For Linux users, and for distribution vendors, quarterly releases may pose a few challenges.
Many have complained that the six-month release cycle followed by Ubuntu
and Fedora is too brisk, but the proposed Firefox release plan will be even
more aggressive — averaging a major release each quarter. This means
that it's likely that Mozilla will release two major Firefox updates during
a distribution development cycle. To be sure, the releases will not be as significant as the Firefox 4.0 update. Mozilla plans to shift the way that it approaches major releases so that there will be fewer features per release, but continual improvements.
This is fine for users who get their updates directly from Mozilla, but it looks likely to pose a challenge for Linux distributions and users who want to run current Firefox releases as part of the distribution. Most distributions have a policy of providing only security updates for packages after the distribution has shipped.
Firefox has already been an outlier in this regard. For desktop Linux releases, Firefox is a key component — and Linux desktop users typically don't want to run an aging or obsolete browser. Firefox's major releases often don't fit well with Linux distribution release cycles — particularly since Mozilla has been known to slip release dates by rather a lot. Firefox 4.0 is a prime example of this, having originally been scheduled for an October release.
In consideration for users, distributions have made special exemptions to update policies by working with Firefox betas during the development cycle and then shipping updates to bring Firefox up to the final release. How will they handle major bumps to Firefox that happen at a much faster pace?
Right now, users on released versions of openSUSE, Ubuntu, and Fedora have the option of installing major Firefox updates from add-on repositories. The openSUSE Project has its Mozilla repository, which allows users to track major updates for stable openSUSE releases. (This should also be suitable for users of SUSE Linux Enterprise Desktop.) Users can also track openSUSE Tumbleweed and receive the stable updates for pretty much all of the major packages, if they're so inclined. Ubuntu currently offers a PPA for new versions of Firefox, and Fedora has the "Remi" repository.
These solutions are fine for users who are familiar with advanced package management. (LWN readers may not consider adding a PPA or RPM repository "advanced," but many users would.) But all of these require users to seek out and add package repositories, which may have been OK when Firefox major releases were spread out by more than a year — but not so much when they become a quarterly affair.
How will the major distributions handle this? Fedora is unlikely to issue major Firefox updates after release, at least for the time being, through the regular update channel. Fedora's Christopher Aillon, who is responsible for the official Firefox packages, says that this is due to the number of packages that depend on the Firefox platform (XULRunner). He adds that "speeding things up won't help that," but that the situation may change as more packages depend on Webkit instead of Firefox/XULRunner "but it's not on the immediate radar."
What about security fixes? Aillon says that it might involve more backporting of security patches, but "it will be nothing new to us. We know the codebase very well and I'm confident that Fedora's packages will remain stable and secure."
As for openSUSE and future stable releases, it's not decided yet how the project will handle Firefox updates. openSUSE's Wolfgang Rosenauer says that "I haven't discussed these plans deeply yet since I was busy
wrapping up Firefox 4 for 11.4. Actually I guess the whole Mozilla project was [wrapping up Firefox 4.0] and most of the planning and discussion will take place from now on."
According to Canonical's Jason Warner, users can continue using the PPA to grab major updates of Firefox. As long as the version of Firefox shipped with an Ubuntu release is receiving security fixes, Ubuntu will stay with that release. However, Warner says that Ubuntu will ship major releases of Firefox as an update if Mozilla stops supporting the earlier release. For example, "We will continue updating FF 3.6 for 10.04 users as long as Mozilla supports that release (typically 6 months after a major release). Once Mozilla stops supporting 3.6 we will update to the latest stable release, whichever number that is at the time."
It looks like Red Hat will make newer releases of Firefox available for
desktop/workstation users of Red Hat Enterprise Linux (RHEL). Actually,
the company has been handling updated releases of Firefox for some time in
its older versions. I pinged Red Hat PR and they responded that Firefox
3.6.x is already being shipped for RHEL 4, 5, and 6. According to Red Hat
the plan is to "stay as close as possible to the latest Mozilla
release, while at the same time ensuring we provide customers with a stable
and secure web browser."
This is largely uncharted territory for distributions and Mozilla. Google's Chrome browser and Chromium project have been doing rapid-fire releases for some time, but have largely bypassed the distributions. Google provides its own packages for Linux users, and only Ubuntu packages Chromium in the default repositories. It would be nice if Mozilla provided native packages for Linux users as well, especially since Mozilla only offers 32-bit packages as the official build for Linux users.
If Mozilla manages to keep to its schedule for 2011 it will be interesting to see how it shakes out for distributions and how they deal with the new development cycle. It will likely require creating some exceptions to policies on shipping major updates rather than just security releases, or perhaps rethinking how releases are handled in general.
to post comments)