The faster release process of Firefox

So Firefox 5 is about to ship. Before anything else, let me translate here two excerpts from this article in French about Firefox 5:

...this is not a major evolution of the browser but more an update to Firefox 4... No visible new feature...

I read and heard a lot about the good things coming from a faster release process. They are downsides too, and nobody really listed them in public. Given the impact on my own daily work, I think it's time to start the feedback loop. Reminder: criticism is always good, it helps spotting issues before they become too big and too painful.

  1. version numbers become meaningless. Firefox 4 was released the 22nd of march; 4.01 the 28th of april. Firefox 5 is about to be released. Firefox 6 and 7 are already announced. But even the press says 5 does not deserve a major version bump. Why not a 4.2 ? What's the mood of a user receiving a Firefox 5 when he/she sees no immediate visible difference with a Firefox 4 and when even the web site he/she reads about it says "no visible new feature?".
  2. corporations cannot follow that speed. Big corporations have to evaluate a new browser against their intranets and often with their corporate partners before allowing it. Even builtin update to minor versions is often forbidden because of corporate rules. Making version number evolve faster puts a huge burden on the IT departments of big corporations: the users see a bump from 4 to 5 and ask for it while a bump from 4.0 to 4.1 does not cause the same reactions.
  3. Google does it. So what? Last time I checked, the Mozilla Manifesto was about openness, freedom of choice and innovation, not competition with WebKit.
  4. the Mozilla ecosystem suffers. Users of tools embedding Gecko (for instance through XULRunner) want applications matching the modernity and security of the last version of Firefox. But it's very difficult for organizations that are most of the time much smaller than Mozilla itself to follow the trend. In the case of BlueGriffon, 1.0 was released the 10th of may. A v5 of Firefox released in the coming days will without any doubt trigger feedback from users wanting a version of BlueGriffon matching that v5's core and I am not ready yet, that's far too fast for me. Even if my tests show I can go on with the last xulrunner, my feature set did not improve that much to bump to 2.0. I can already hear the counter-argument: don't mention Firefox versions, mention Gecko versions. But guys, that's exactly what I said about the "Powered by Mozilla" stamp: a lot of people have just no idea what Mozilla or Gecko are! They know the name "Firefox", they partly ignore "Mozilla" and totally ignore "Gecko". Firefox is the only reference that does matter here.
    Anyway, moving to a new version of Firefox, its toolkit and Gecko will always require from 3rd-party embedders tests and often adaptations to their own code. That takes time, and the faster release process does not really care.
    By the way, don't the marketing teams at Mozilla suffer too? A major version every 16/18 weeks, wow...
  5. Fragmentation and workload for embedders. If embedders want to anticipate just a little bit what's going to happen in Firefox or the toolkit or Gecko, the time investment just multiplied by 3 or 4. For most of us, that's just not feasible and we'll follow only the about-to-be-released tree and we will probably always lag. In other terms, we won't detect bugs caused by changes in the other ones, the to-be-released-in-16-and-32-weeks trees and we'll let pass regressions or issues that should probably be detected immediately.
  6. Web authors will have to sniff even more browser versions. It's a browser war time and new cool kids are around the block. 3D Transforms, Animations, Reflections, Device APIS and many, many more. A faster release process means a greater fragmentation of the browser landscape and that's absolutely terrible for web authors.

I'm not saying a faster release process is 100% bad. I'm only saying here it has important downsides that are in my opinion important enough to trigger a feedback loop. Why not a faster release process but with minor version numbers instead of major version numbers? In particular, the side-effects on the Mozilla ecosystem and the Web authors' community seem to me really underestimated.

Update: I forgot to mention the huge impact on add-on authors... And add-ons are one of the most influential points in the success of Firefox in front of Chrome.


1. On Tuesday 21 June 2011, 09:48 by Henri Sivonen

#1: This will probably cause confusion initially, but it will pass. Chrome users don't seem to mind if the UI doesn't change visibly on each release. As for why not 4.2? For site compat testing and add-on compat purposes, the version number needs to be known at the start of the cycle when you don't yet know how big features end up in the release train.

#2: I think the competitiveness of the public Open Web against proprietary platforms (Flash, iOS) is more important than letting enterprises write browser-locked intranet code.

#3: Google doing it is evidence that it can work.

#4: Marketing needs to go into a mode where version numbers are meaningless and "Firefox" sans version is what's marketed (see #1 and #3).

#5: Embedding is already a lost battle that WebKit won at least until Gecko gains a multi-process story that'll allow Gecko to run in a separate process from the embedder.

#6: Web authors shouldn't care about old releases. The idea is that the new releases replace old ones fast. Chrome manages to migrate their userbase over to a new version in about a week. With Firefox, extension compat is a major contingency, though.

2. On Tuesday 21 June 2011, 09:54 by cedricv

FWIW one way to mitigate the issue of meaningless version numbers could be to change to date-based versioning, as does Ubuntu and others.
Firefox 11.06 instead of 5, Firefox 11.08 instead of 6 and so on.

At least this would make clear that there is no 'big feature' to expect in any other version.

3. On Tuesday 21 June 2011, 10:12 by Xavier

Not a big fan myself of the sudden version jump. I'm all for Firefox getting more releases (yay!), but I still like my version numbers to be meaningful. The message they are sending is that any new version is a major version? Oh well.

Chrome users have always been used to have meaningless version numbers, and that's fine. Here Mozilla is being the follower, for a reason that I can't immediately see as sound.

The only way I can make sense of it is that, major or minor, users are ALWAYS asked to update as soon as possible (major: plenty of features, update! minor: oops, fixed it, update!), so in that way version numbers are only relevant to versioning systems, and geeks.

Apparently talking about version numbers is trolling, if Anthony Ricaud's latest post is to be believed, so I'm guessing I'm an old guy, attached to his old habits, and Chrome is the new generation of hip stuffs, so it's only natural for Mozilla to acknowledge that.

Still, it feels weird to have had a classic versioning pattern for YEARS (aaah, Phoenix), and now that there's a new kid on the block, change it to a whole something else. The marketing mistake here might not be version numbers, but rather giving the idea that Firefox is fearing for its leadership.

4. On Tuesday 21 June 2011, 10:14 by Stéphane Deschamps

I understand, more or less, the need to feature a higher version number, to cater for questions along the lines of "oh, this browser must be old, it's only its fourth generation: look how the others are much more mature, being around tenish". Really, I can understand the Marketing proposition.

Yet I agree with all of Daniel's worries.

Major changes are harder to follow, what with extensions being targeted through their install.rdf towards major versions (3.*, 4.*); I'm still using 3.6 at work for this very reason. Too many extensions to check for. At home I went for 4 (Ubuntu 11.04 on a new machine), and half my extensions went on extended vacation. (by the time I wrote this comment, Daniel has already added an update mentioning add-ons exactly along the same lines).

@Henri: how is a major versus minor version number more competitive? We ask for open web, we ask for fast rendering, we ask for better reliabity, better security. For the sake of discussion, how on earth is 5.0 going to be faster, safer, more reliable than, say, a hypothetical 4.2?

As for new releases quickly replacing old ones, yah: in bigger companies (and by bigger I mean tens of thousands of people), we're still using IE7. Firefox is not being updated on many workstations because people don't have administration rights, even when it was installed as a courtesy by administrators two years ago. Frequent major updates have a cost. Yes, I know people should code websites and services with standards in mind, but sometimes people don't. Most of the time people don't, as we all know and even if we've been evangelising for a long, long time.

I have no solution but I have the same questions as Daniel. Thank you Daniel for taking the time to formalise them (and force me in the process to comment here as well).

5. On Tuesday 21 June 2011, 10:15 by Patcito

As a web dev I'm happy with the new release process. Browser sniffing is bad and shouldn't be used in the first place. Graceful degradation and progressive enhancement are where it's at, it's now ridiculously easy to do thanks to Modernizr and yepnope. As for extensions, they never break in chrome so I guess mozilla can do something about that, weren't they going to update most of them to next anyway? For the rests of your points I totally agree with Henri Sivonen.

6. On Tuesday 21 June 2011, 10:17 by glandium

It was mentioned on the newsgroups that we should have long term support for a given release every x release, where x would need to be determined. I don't know if this is going to get any further, but I think that if we want the Mozilla platform to live, we should definitely commit to it.

7. On Tuesday 21 June 2011, 10:25 by Fallen

I very much agree to this and think the process should be reviewed. If there are releases every 6 weeks, this means we will be at Firefox 14 in a year, Firefox 23 in two. While this might be nice from a marketing perspective, it doesn't cut well for the Firefox community.

Another issue you only partially mentioned is the consequence for extension authors. While AMO will provide a version bump mechanism, this will cause non-AMO hosted extensions that don't release as often to just increase their maxversion to 9999.*. In the long term, this will mean that the user experience w.r.t. extensions will suffer, because there will be more than a few extension on the web that are installable in the latest Firefox, but are no longer functional.

Another issue for extensions with binary components is the vast number of additional branches the new release process means. For my part, if we follow every branch that the new process has to offer, then Lightning might need to be compatible with comm-central, comm-aurora, comm-miramar, comm-beta, ... We simply don't have the resources to support all those branches and unless the binary components are by magic compatible, we have to limit our nightly builds to two branches (i.e comm-central/comm-whatever-is-next)

8. On Tuesday 21 June 2011, 10:47 by Henri Sivonen

@Stéphane: 5.0 isn't faster, safer, more reliable than a hypothetical 4.2. It's just simpler to increment an integer every time and to do it at the start of the cycle when you don't know if the cycle end up having major or minor stuff in it. It's simpler to do at the start of the cycle so that the new UA string gets more testing and so that add-ons don't need to bump compatibility declarations many times during a cycle. Also, deciding if a release is major or minor on a case-by-case basis would emphasize numbers for marketing and fail to make them meaningless when the idea is that the user subscribes to a continually updated product stream called Firefox.

9. On Tuesday 21 June 2011, 11:25 by Steffen

> By the way, don't the marketing teams at Mozilla suffer too?
> A major version every 16/18 weeks, wow...

It's actually 6 weeks, except for Firefox 5, which was on an even shorter train.

Firefox 5 will be released today.
Firefox 6 will merge to Beta in 2 weeks, and will be released in 8 weeks.
Firefox 7 will merge to Aurora in 2 weeks, will merge to Beta in 8 weeks, and be released in 14 weeks.
Firefox 8 work will start work on mozilla-central in 2 weeks, will merge to Aurora in 8 weeks, to Beta in 14 weeks, and be released in 20 weeks.
See http://mozilla.github.com/process-r...
and http://hg.mozilla.org/users/clegnit...

10. On Tuesday 21 June 2011, 11:25 by Anthony Ricaud

About version numbers, note that all marketing material will not mention version number from now on. And I see the version number problem as completely independent from the new release cycle (this is why I didn't want to discuss it in my blog post).

About addons, all addons distributed through addons.mozilla.org are automatically updated if possible. See http://blog.mozilla.com/addons/2011... for more details. That doesn't solve everything though.

About browser sniffing, more and more tools allow developers to not rely on version sniffing. They may not be widely used but I believe updating version number more often will boost feature detection just by making version sniffing harder.

Otherwise, I completely feel the other points (2, 4, 5 and addons) and we'll see if those concerns outgrow the benefits.

11. On Tuesday 21 June 2011, 11:45 by Steffen

Binary components will break with every version. But as long as Mozilla provides enough machines to produce builds for 3 branches (central, aurora, and beta), and run unit tests on them, where's the problem?

On the other hand, I'd consider integrating the binary components into Thunderbird; the js parts don't need to change as often.

12. On Tuesday 21 June 2011, 11:51 by José

What I find even more confusing is that Thunderbird will have an equal release cycle. Why on earth does an email client need to be updates so often?

13. On Tuesday 21 June 2011, 11:59 by Steffen

@José: security. Compare the previous Thunderbird releases: 3.0.11, 3.1.10.

14. On Tuesday 21 June 2011, 12:09 by voracity

The suggestion glandium refers to is critical to keeping life sane and goes a long way to solving 2, 4, 5 and addons. If there is 1 LTS blessed release each year, that'd be very nearly perfect. e.g. BlueGriffon can be based on the latest LTS, which users would easily understand.

There is the risk, though, that people will consider the LTS the only important release, but I think the risk is minor considering most users will get auto updates.

15. On Tuesday 21 June 2011, 12:14 by Tristan

For those who did not get the memo, browser sniffing is bad :-)

16. On Tuesday 21 June 2011, 12:15 by kazé

glandium ++

I agree with Daniel on points #2 and #4, but I don’t think this is directly related to the faster release process. To put it another way: the new release process is fine imho but we’re missing a “long-term support” (LTS) branch for corporations and the Mozilla ecosystem.

I understand that maintaining an “old” branch would double the workload of the security team but I believe the Mozilla platform will suffer from the new release process. Most of the new features are browser-specific and most XUL apps don’t require them as badly as Firefox does.

What I’d love to see is:
 • a major / stable / LTS branch (say, 4.0) for corporations and XULRunner apps;
 • time-based Firefox releases (say, 4.1, 4.2 and so on) for individuals who can upgrade Firefox regularly.

That could be a way to preserve the Mozilla platform (LTS) while pushing the web platform forward. My two cents.

17. On Tuesday 21 June 2011, 13:18 by Simon

I couldn't agree more. Another argument could be the silly version numbers above 10. How about Firefox 43 ?

18. On Tuesday 21 June 2011, 13:45 by Ben Hearsum

Web sites shouldn't be sniffing versions, they should be sniffing capabilities.

Also, we're getting away from publicising version numbers altogether. Especially given that, I don't see the point in arguing whether 4.2 is better than 5.

19. On Tuesday 21 June 2011, 14:21 by Xavier

Copying Chrome's versioning pattern is silly, Firefox should mimick the one used by TeX (π) and Metafont (e). How about φ ? ;)

20. On Tuesday 21 June 2011, 19:46 by celui

@Xavier, φ is not transcendental...

21. On Tuesday 21 June 2011, 20:53 by njn

I like the rapid release model, I just wish the version numbers were 4.1, 4.2, ..., 4.9, 5.0, 5.1, ..., 5.9, 6.0, etc.

22. On Wednesday 22 June 2011, 04:26 by Fitzcairn

Tiens d'ailleurs c'est peut etre le moment de mettre à jour Freerecord enfin je dis cas je dis rien :')

Merci pour le développement de cet add-on ;)

23. On Wednesday 22 June 2011, 05:25 by Michael B.

To solve the problems with industry, you could take a page out of the Linux distros' playbook. Have a new release every 6 months. Every 2 years, have an extra stable release for industry that might have some security and bug fixes backported until the next 2-year release is released. I don't know if this is the best option, if it will pull many development hours away from advancing the browser as a whole, or drive up costs much. It might be worth considering if it can help keep and bring in many new users in industry.

24. On Wednesday 22 June 2011, 06:51 by yt75

Bonjour, I sent you a mail from yt*****@hotmail.com, did you receive it ?

25. On Wednesday 22 June 2011, 08:20 by Henri Sivonen

@Micheal B.: Doing what you suggest would mean that more users would be using a two-year-old legacy browser. Web authors would feel they need to support the two-year-old browser. This would be a failure in terms of the mission to move the Web forward. Maybe some of those users are now on IE8, but giving them the opportunity to be on another legacy browser doesn't seem like an improvement.

26. On Wednesday 22 June 2011, 12:11 by Pepe

I really hope that Mozilla is gathering feedback on this. Facebook's Firefox page contains a lot of negative comments regarding add-on incompatibility. These users will suffer from this problem every 6 weeks now.

27. On Wednesday 22 June 2011, 19:11 by pd


Finally someone in the Mozilla community has the courage to stand up to this rapid-release madness!

Firefox 5 is barely a point release. At least Google seems to be able to release at least one major feature every time they release a so-called 'major' version. You are not Google, you are much smaller. Do not try to compete on a rapid-release basis for which Mozilla is not suitable.

The history of Mozilla is getting embarrassing. First dumb-down the interface to reduce the barrier to entry for IE switchers. Motivation: IE. Second rapid-release. Motivation: Google. I realize you need to be aware you're product exists within a competitive market however you do not have to be so damn reactionary!

Now I hear there's no more security patches for version 4! WTF is going on at Mozilla? Have you lost your minds? All of a sudden there's a potentially huge security gap for those sticking to Firefox 4 whilst waiting the inevitable (?) wait for add-ons to update. Instead 3.6.18 gets released and so you're screwing version 4 users?

Mozilla have lost the plot. It is very depressing. I'll never touch Chrome so you're forcing me to tolerate a second-rate browsing experience. Sounds like Microsoft circa 2003.

28. On Thursday 23 June 2011, 04:48 by Kevin Dangoor

Regarding having a major feature in each release: we had a *ton* of new stuff in 4, but it wasn't all created at once. I suspect that as we get going with the release trains we'll start having a major new feature in many releases just by virtue of different groups landing things at different times.

29. On Thursday 23 June 2011, 11:17 by Olivier T

Would love to hear someone at Mozilla explain “You know what? The goal is really to just get rid of version numbers, at least in communication and in the public's mindset – and get everyone to think in terms of an always-up-to-date offering?”.

At least that's what I read - as a subtext, when Anthony writes in comment #10 “note that all marketing material will not mention version number from now on”.

Wouldn't surprise me if this were a logical offspring of that same culture which gave us CSS (and HTML5) without versioning mechanisms. Opinion on whether this is good or bad is left as an exercise for the reader.

30. On Thursday 23 June 2011, 19:08 by yt75

N'est-ce pas aussi un moyen de virer (ou gêner) Google toolbar ? (que l'on ne peut pas installer sur cette v5)

31. On Friday 24 June 2011, 00:04 by Paul R

@Olivier T - Yes. Transcending the version number is exactly what we wanna do, and this is what the future is made of.

32. On Friday 24 June 2011, 07:04 by Daniel Glazman

@Pauk: tu devrais considérer la possibilité que vous vous plantiez majestueusement..

33. On Saturday 25 June 2011, 03:52 by KMakk

My beef is with the fact that in its panic to keep ahead of Chrome's nipping at its heels, Firefox is releasing too fast now for add-on developers to keep pace. I am still doing without some of my best add-ons that aren't even yet ready for FF4, and now FF5? Prompted today to upgrade to FF5, I noticed the list of add-ons that will not yet work for FF5, including Google Toolbar.

I'm outta here. This coming week, I move to Chrome and learn it. Way to give us good reasons to switch to the competition, FF.

34. On Sunday 26 June 2011, 01:35 by James Napolitano

Maybe the rapid release process is really a roundabout plan to get more cakes from the IE team ;)

35. On Sunday 26 June 2011, 21:48 by Michael

I couldn't agree more. This rapid release version is deadly for Firefox for one reason - Addon developer. I don't want to update everytime to the next version. I just gave up to do - even if many are asking that I should release new version.Go back to the reliable system where the first number stands for a major release, the second number for new features and third number for bug fixes. Than I would consider to come back to Firefox and update the addons. My time is to costly just keep track of silly version numbers!

The Mozilla foundation should make a clear announcement that is was not wise to try to copy other version systems and users and especially developer have been asking to bring the old system back.

36. On Monday 27 June 2011, 03:46 by Holly

So will future versions of Firefox silently auto-update themselves? Or how else do they intend to get rid of version numbers? Either Firefox does what Chrome does (or goes back to feature-driven slow release cycles) or we get fragmentation hell. Having a large install base of no-longer-supported versions makes Mozilla look like Microsoft.

37. On Tuesday 28 June 2011, 12:17 by Billi

In my opinion Mozilla will be kicked out of the companies quicker than you can say "Ouuuch"! This release policy will lead to a very quick shift in thinking about FF support in the commercial world. If you don't care for it Mozilla, ok, let's go on. But if you want to stay THE alternative to IE you should think twice about this decision. I can't help myself but IMO the main reason why open source products are (mostly) niche products is because open source developers don't understand the needs companies have: costs, stability, reliability and continuity. If you don't care about it companies will use other products that fulfill these criteria. If you're targeting at the home user only I'll say it with Barack Obama: "Time for change is now."

Just my 0.02€

They posted on the same topic

1. On Friday 1 July 2011, 11:47 by Stanislas Quastana's blog on TechNet

Navigateurs Web et sécurité : faire le bon choix et comparer

[Note préalable : ceci est une mise à jour d’un article précédent. Pour ceux qui l’ont déjà lu, la mise...