Beyond Firefox 4.0: Handling an accelerated development cycle
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.
| Index entries for this article | |
|---|---|
| GuestArticles | Brockmeier, Joe |
Posted Mar 10, 2011 1:26 UTC (Thu)
by jetm (subscriber, #61129)
[Link] (1 responses)
Posted Mar 10, 2011 17:25 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link]
Just that they will have to roll over lots of other packages in sync. That is the problem, not the updating of a single package (or a few related ones).
Posted Mar 10, 2011 1:41 UTC (Thu)
by idupree (guest, #71169)
[Link] (2 responses)
Posted Mar 10, 2011 2:53 UTC (Thu)
by joey (guest, #328)
[Link] (1 responses)
Posted Mar 10, 2011 3:50 UTC (Thu)
by dberkholz (guest, #23346)
[Link]
Posted Mar 10, 2011 3:36 UTC (Thu)
by Sufrostico (guest, #68053)
[Link] (7 responses)
- Google Chrome is version 10
They want to reach the same numbers of Google Chrome. To Developers is non-sense but for most windows end users, numbers (not even features) matters.
Kind off the same thing that Slackware did years ago (Jump some version numbers just for marketing).
Posted Mar 10, 2011 14:14 UTC (Thu)
by bryanlarsen (guest, #26230)
[Link]
It's also the same model the Linux kernel uses. Given that the 3rd number is the only significant one these days, we might as well call the latest linux kernel "38.rc8".
So no, I don't think it's marketing -- I think it's just good engineering. Using the Linux kernel as your model for release cycles is probably not a bad idea for most projects.
Posted Mar 10, 2011 15:02 UTC (Thu)
by jzb (editor, #7867)
[Link] (5 responses)
It is not, at least not in the sense that you're suggesting. Firefox does not make an inordinate fuss over its version numbers - pretty much only to the extent required to encourage people to upgrade quickly. Google does not make much of a fuss about version numbers at all.
It is a strategy to compete with Google Chrome by rolling features out much more quickly. If you've lived with the stable Firefox release 3.6 through its lifecycle, rather than upgrading to the betas for 4.0, you've had the same feature set for close to a year. Chrome users, on the other hand, have continued to get new features on a regular basis.
Firefox is trying to change that and match Chrome's development style by pushing updates out more quickly.
Posted Mar 11, 2011 15:30 UTC (Fri)
by sorpigal (guest, #36106)
[Link] (4 responses)
Posted Mar 11, 2011 22:15 UTC (Fri)
by anselm (subscriber, #2796)
[Link]
I say they want to catch up with Internet Explorer, which is around version 9 these days.
Posted Mar 14, 2011 10:00 UTC (Mon)
by jezuch (subscriber, #52988)
[Link] (2 responses)
Posted Mar 14, 2011 13:49 UTC (Mon)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Mar 14, 2011 14:02 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link]
Posted Mar 10, 2011 6:00 UTC (Thu)
by AndreE (guest, #60148)
[Link] (4 responses)
Posted Mar 10, 2011 8:14 UTC (Thu)
by viiru (subscriber, #53129)
[Link] (3 responses)
It's not quite so simple. How does the distinction go with for example Firefox? It might seem to be an obvious case for "world" as it is a end user application. But is it? Let's take a quick look. On a Debian Squeeze system, there are 39 packages that depend on xulrunner (the rendering engine / user interface library of Firefox). You can't actually update Firefox without updating xulrunner, and if xulrunner is not fully backward compatible (it usually isn't), you may need to update the other 38 packages as well.
Some have claimed that Debian should ship an embedded copy of xulrunner with every depending package, but that just moves the problem to security updates (which are extremely frequent for our example case xulrunner), where instead of updating one package the security team needs to update all 39.
Does this help you see what the problem is?
Posted Mar 10, 2011 8:36 UTC (Thu)
by epa (subscriber, #39769)
[Link]
But then, of course, somebody would need to backport security fixes to the stable xulrunner, so it's not that simple.
Posted Mar 10, 2011 8:45 UTC (Thu)
by AndreE (guest, #60148)
[Link]
Ultimately, I think a more granular update policy makes a lot of sense, and not just in this case. There is no reason that the firefox, xul-runner, or Open Office versions need to be as stable as the kernel version, Xorg version, or DE version throughout the lifetime of a distro.
Posted Mar 11, 2011 1:18 UTC (Fri)
by nicooo (guest, #69134)
[Link]
Yeah, xulrunner.
Posted Mar 10, 2011 8:12 UTC (Thu)
by rhertzog (subscriber, #4671)
[Link]
Posted Mar 10, 2011 10:41 UTC (Thu)
by kragilkragil (guest, #72832)
[Link] (1 responses)
Posted Mar 10, 2011 17:28 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link]
And then Mozilla will have to take over maintenance of the 39 xulrunner-dependent packages in Debian, and in Fedora, and...
Posted Mar 10, 2011 16:30 UTC (Thu)
by patrick_g (subscriber, #44470)
[Link]
Posted Mar 10, 2011 22:26 UTC (Thu)
by elanthis (guest, #6227)
[Link] (3 responses)
Red hat, fedora, debian... None of them should be shipping 50,000 packages, as the vast vast majority of those should be upstreams responsibility.
Yes, distributions currently apply a lot of fixes to upstream. Because they have to because they taught upstream to be lazy idiots. If upstream were forced to actually take responsibility for their software, then the software worth using would shape up (If nothing else, the hordes of duplicate package maintainers for an app could just go work on upstreams repo/packages directly), and the poorly maintained apps will die off like they rightly deserve.
There is not one single _real_ technical dilemma with this. Just lots of whining and screaming and idiotic rambling by distro developers that care more about their control-complex than actual usability or user support. All of the barriers to having upstream package their software and distribute it (with full cross-vendor dependency resolution) are artificial barriers intentionally created and enforced by the distribution developers.
Posted Mar 11, 2011 1:36 UTC (Fri)
by jrn (subscriber, #64214)
[Link]
Do you remember what life was like before the major distributions? (I don't mean to point to any particular conclusion by this. You just might find it interesting to look into.)
Posted Mar 11, 2011 15:34 UTC (Fri)
by sorpigal (guest, #36106)
[Link]
Posted Mar 11, 2011 18:53 UTC (Fri)
by christoph_d (guest, #62481)
[Link]
would be interesting how you are going to handle soname changes or want to ensure that applications are not using library versions where security support ended years ago
Posted Mar 12, 2011 13:38 UTC (Sat)
by eduard.munteanu (guest, #66641)
[Link] (1 responses)
It's really good to see a move towards releasing more often, but messing up with the versioning scheme in this way is bad. Other projects are able to keep up with similar goals without resorting to such tricks. Just release when something gets done, not just because a few months have passed.
Maybe the problem lies in merging too much too soon? Maybe those features should stay out of the main tree until most issues/bugs have been ironed out? I don't know, I'm not involved in Firefox development, but perhaps there are better solutions to this problem.
Posted Mar 21, 2011 5:03 UTC (Mon)
by dlang (guest, #313)
[Link]
it sounds like you are under the impression that the developers introduce new stuff for a .0 release and then only fix bugs for .1, .2, etc.
the sad reality is that they are introducing new stuff for every release, so there are no releases that are as stable as you are thinking they are.
on the other hand, as the kernel development has shown, you can get good results both for stability and for rapid introduction of new features with a rapid release cycle.
but when you do this sort of rapid release cycle, you really don't have a reason to believe that any release is significantly better than any other (without testing). how good the releases are will depend a lot on the testing that gets done on the patches before they are put in upstream. it may be that there is reason for a series of bugfix-only branches (like the kernel -stable series), but we'll have to see at what rate new bugs are introduced, and who is willing to backport the bugs for how long.
Beyond Firefox 4.0: Handling an accelerated development cycle
Beyond Firefox 4.0: Handling an accelerated development cycle
Beyond Firefox 4.0: Handling an accelerated development cycle
Beyond Firefox 4.0: Handling an accelerated development cycle
Beyond Firefox 4.0: Handling an accelerated development cycle
Beyond Firefox 4.0: Handling an accelerated development cycle
- Mozilla Firefox is version 3.6
Beyond Firefox 4.0: Handling an accelerated development cycle
Beyond Firefox 4.0: Handling an accelerated development cycle
Then why not go with 4.1, 4.2 and 4.3 instead of 5, 6 and 7? If it doesn't matter and users don't care and it's not about marketing how about continuing a practice that makes sense and makes me happy?
Beyond Firefox 4.0: Handling an accelerated development cycle
Beyond Firefox 4.0: Handling an accelerated development cycle
Beyond Firefox 4.0: Handling an accelerated development cycle
Beyond Firefox 4.0: Handling an accelerated development cycle
Beyond Firefox 4.0: Handling an accelerated development cycle
less-418 was released on January 8, 2008.Beyond Firefox 4.0: Handling an accelerated development cycle
Beyond Firefox 4.0: Handling an accelerated development cycle
> system /world distinction like in FreeBSD would allow distros to maintain
> system stability while allowing users to run the most recent applications
I don't understand why distros do not have a 'xulrunner-stable' which other apps depend on and which doesn't have to update whenever Firefox bumps its internal version of the XUL libraries. Since Mozilla (AFAIK) makes no commitment to provide a stable API for xulrunner, this seems a simple necessity.Beyond Firefox 4.0: Handling an accelerated development cycle
Beyond Firefox 4.0: Handling an accelerated development cycle
Beyond Firefox 4.0: Handling an accelerated development cycle
Beyond Firefox 4.0: Handling an accelerated development cycle
Beyond Firefox 4.0: Handling an accelerated development cycle
Beyond Firefox 4.0: Handling an accelerated development cycle
>>> especially since Mozilla only offers 32-bit packages as the official build for Linux usersBeyond Firefox 4.0: Handling an accelerated development cycle
Really ? There is a Mozilla.org FTP server with x86-64 builds : ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/4.0rc1/linux-x86_64/
It's not official ?
Beyond Firefox 4.0: Handling an accelerated development cycle
Beyond Firefox 4.0: Handling an accelerated development cycle
I agree, so long as upstream vendors agree to stay in compliance with Debian policy. Third party apps that crap all over my filesystem and do things their own way when a policy exists tend to get uninstalled rapidly.
Beyond Firefox 4.0: Handling an accelerated development cycle
Beyond Firefox 4.0: Handling an accelerated development cycle
Beyond Firefox 4.0: Handling an accelerated development cycle
Beyond Firefox 4.0: Handling an accelerated development cycle