“Why did my Firefox suddenly go from 3.6 to 4.0 to 5.0 in the space of half an hour?” asked my friend on the phone, in the middle of what was otherwise a conversation about role-playing games.
“Because the automatic updater system is working?” I said.
“Was Firefox 4 really so broken that you had to kill it after three months?” he asked. Except he used a ruder word than “broken”.
“No, not at all”, I said, remembering the giant launch party we had had for Firefox 4. It did feel kind of like we told everybody “Firefox 4 is the greatest thing ever, and it’s finally here! Download it now! OK now it’s obsolete already.”
“It’s just that we’ve got this new rapid-release schedule going”, I continued, “where we push out the new releases every three months, so that users always have the latest bug fixes and speed improvements and stuff.”
“OK, well, it says that Perapera-kun (the extension I use to translate Chinese) is no longer compatible. I really needed that extension.”
Oops.
Some backstory:
Firefox 3.6 was released on my 30th birthday – January 21, 2010. Firefox 4.0 was released on March 22, 2011: 14 months later.
It was very frustrating both to our developers and our users that bug-fixes, speed-ups, and features that were completed in, say, February or March of 2010 had to sit unused on the shelf until every part of the the enormous monolith called Firefox 4 was ready to launch. By early 2011, users of Firefox 3.6 were complaining about problems that had already been fixed for a year; but they didn’t have the fixes because our monolithic release schedule didn’t let us give them the fixes.
Our monolithic release schedule also meant we couldn’t respond quickly to the rapidly changing and highly competitive browser market. Chrome and IE aren’t stitting still. There was a feeling within MoCo that the fourteen-month wait between Firefox 3.6 and Firefox 4.0 could have killed us competitively. Almost did kill us.
Given that, moving to a rapid release schedule — releasing a new Firefox on a regular, frequent schedule, just to give users whatever improvements we have for them, even if it’s not a huge splashy new release — seemed like pure win. It took a lot of effort inside the company to make that transition. We had to really focus on it, pull together, overcome many obstacles. That we shifted over to a whole new development process and still shipped Firefox 5 on time, even though it was just a tiny incremental update, felt like an enormous victory.
And yet… People on the Interenet are calling the new release plan a kick in the stomach, saying we’re committing corporate suicide, saying that they feel “suckered” and that “Mozilla is creating something you can’t rely on” (comment thread). They’re even making us into Hitler. (Hitler in his bunker, no less — the meme used to indicate not only that someone is the bad guy, but that they’re losing and in denial about it as well.)
When I first started reading some of this backlash, I was puzzled. Were people really getting upset because we released Firefox 5 so soon after Firefox 4? Isn’t releasing rapidly a good thing? Don’t they want new bug fixes and speed improvements as soon as possible? Yes, we stop supporting older versions, but it shouldn’t matter, because everybody should automatically be upgraded to the latest version, right?
Or were they complaining that there was too little change to justify a version number bump? Did people really care that much about version number schemes? (As a rule, I don’t pay much attention to debates over version numbering schemes, because they bore me to tears.) If we had released the exact same thing but called it Firefox 4.1 would they have been happy?
In diagnosing usability problems, we often have to look beyond what users say they want in order to perceive the underlying problem. We want to treat the disease, not the symptoms.
In this case, the symptom is the complaints about the pace, and the rapidly-increasing version numbers, of new releases. But new releases are good, and version numbers are just numbers. What’s the disease?
We thought that the new rapid release process was pure win. We underestimated two things:
The number of extensions that are breaking each time we raise the version number. And the number of people who need a stable, long-term-support version of Firefox.
First, many extensions — like my friend’s favorite extension, the Chinese popup translator PeraPeraKun — break each time a new release comes out. Faster releases means faster breakage, which means more effort for developers and for users to keep their extensions compatible.
There are two causes of extension breakage. An extension may break because we changed an API it relies on, meaning it won’t work on the new Firefox version until the extension developer goes in and rewrites the part that uses the API. But an extension may also break just because of the version number changed, even if there is no API change. This is because extensions have metadata files specifying which versions of Firefox they run with; if your extension’s metadata file says “I work with Firefox 3.5 – 4.0” then as soon as 5.0 comes out, your extension will be marked as incompatible, even if there is no API change. So an extension can lose compatibility for bureaucratic reasons — its “paperwork” isn’t up-to-date — even if there’s absolutely nothing wrong with it. It would work if that file was changed (or if add-on version compatibility checking were turned off). But an end user has no way of telling the difference between a “real” breakage and a “paperwork” breakage.
This system made sense back when every new major version number was fairly guaranteed to have API changes. In the new rapid-release world, the version number is now changing every few months, but API changes are no more frequent than they were before. API breakage is a problem that existed before; the rapid-release schedule hasn’t made it any worse. But the number of paperwork breakages has skyrocketed under the rapid-release schedule.
We can say that “80% of extensions remain compatible” but that’s hardly consolation if the one extension you rely on is not part of that 80%. Ideally its developer should be updating it; but what if its developer is nowhere to be found? What if its developer got fed up with having to change the metadata file every six weeks and stopped maintaining the extension? Maybe that one extension was the only reason you were using Firefox; then what? You could try to go back to your old version of Firefox that still works with the extension… if you can figure out where to download it, and if you can figure out how to turn off auto-updates. We don’t make either of those things easy. Even if you succeed, you’re now stuck on an obsolete browser version and you’re not getting fixes for the latest security vulnerabilities. This is a problem.
I think that long-term, we ought to move away from the whole concept of a “maximum compatible version number” in a metadata file. We should try to provide a compatibility layer with a guaranteed-stable API, so that even if we change the underlying implementation, extensions written to the compatibility layer will still work. That’s one of the goals of the Jetpack project.
The second thing we underestimated: the number of people who need a long-term-support version of Firefox. By “need” I mean that their choice is between using a long-term-support version and not using Firefox at all. Imagine being the IT manager for a large organization, a school for instance; you’d like to keep your browsers up-to-date but you have a lot ofX other things to worry about, and any major change to browser functionality means you’re going to have to re-write documentation, re-test your intranet web-apps, re-install any extensions you rely on, and re-train your users. All of these things cost you time and money. You want a browser that can be relied upon to behave consistently over time. Your ideal browser is one that automatically gets security updates, but not other kinds of updates.
If Mozilla isn’t going to provide a browser like that, you’ll look elsewhere. Simple as that.
Maybe in addition to “nightly”, “aurora”, “beta”, and “final”, we ought to have a fifth update channel. Call it “long-term stable” or call it “security updates only”; whatever we call it, there’s a huge demand for something like that, and we’re not providing it right now.
We need to start by admitting that we screwed up. We have to listen to our community when they tell us what a serious problem this is for them. We have to stop treating complaints about version numbers as if they were just a misunderstanding; yes, they’re “just” version numbers, but under the smoke of the version number argument there is the fire of a real problem. Or rather, two problems.
I still think that moving to rapid releases was a good idea on the whole. It has a lot of advantages. But like many big changes, it’s solved one big problem while creating two smaller problems. We need to face those problems and deal with them. I’m confident we can solve them, but first we need to stop pretending that they don’t exist.
Not The User's Fault 
July 18, 2011 at 7:53 pm
We all didn’t like 14 months, but going to six weeks?
Surely there was some middle ground there…
July 18, 2011 at 8:14 pm
“It’s just that we’ve got this new rapid-release schedule going”, I continued, “where we push out the new releases every three months”
Every 6 weeks! 🙂
http://blog.mozilla.com/channels/2011/07/18/every-six-weeks/
July 18, 2011 at 8:19 pm
You’re right, of course.
I get “time that one release bakes for” and “time between successive releases” mixed up a lot, especially when I’m on the phone talking about role-playing games.
July 18, 2011 at 8:35 pm
I still don’t know _why_ people like an LTS where everything breaks after 6-12 months better than staying on the normal release channel where at most (if at all) tiny bits break every 6 weeks.
July 18, 2011 at 8:47 pm
Because an LTS gives us time to prepare for the breakage. As an add-on developer, I don’t have time to screw with all of my add-on developers every six weeks.
And you say “tiny” breakage, but as is pointed out in this post, if your add-ons break every six weeks, that’s not tiny.
And have you looked at the list of Firefox 5 breakage from:
http://blog.mozilla.com/meeting-notes/archives/592
Clearly it’s not so tiny.
July 18, 2011 at 8:49 pm
“I still don’t know _why_ people like an LTS where everything breaks after 6-12 months”
It’s not just the total time – generally with LTS there’s also more overlap, so you have a window of 6 months or something where both the old version and the new version are supported, and you can choose when to switch. With the Firefox schedule, the previous version is unsupported (and has published security flaws) basically instantly the new version is out.
“at most (if at all) tiny bits break every 6 weeks”
Hopefully it will improve, but currently it’s not only tiny bits – extensions with binary bits break totally, every time, and some popular ones are not yet available for Firefox 5, some weeks after the release.
July 18, 2011 at 8:59 pm
Ive been living this cross-browser development hell since 1994. I have given this alot of thought. Even with a magic wand and some unicorns, I don’t think there is a sensible answer.
Ultimately, I’d like to see a world flipped upside-down. I want to define ONE browser/version that I tested in and know that every client would see it that way. Adobe AIR is like this.
Basically, let the publisher decide which “rendering engine” to use. And unicorns, that would be nice.
July 18, 2011 at 10:35 pm
You’re abosolutely right about the need to improve the extension compat situation and we’re hard at work on that with better tooling (for us and for extension developers) and more stable APIs with the SDK and evangelizing JSCtypes. We’ll get there on those and they’re pretty well understood and making progress.
There’s another piece you’re missing though. We don’t yet have a very silent update process. Even putting add-ons aside, if a user is being interrupted with a sometimes long and complicated process of updating every 6 weeks or so, we’re going to get complaints about the pace of updates. When we can silence most of that (avoiding UAC prompts, applying most of the update in the background so minimal time is needed on restart, moving add-on compat checks to later in the process, killing the what’s new tab, etc. etc.) we’ll make users a lot happier. Eventually, most won’t have to deal with the “update fatigue” they do today.
This two was pretty well understood (like the Add-ons space) when we made this change and we knew it was going to be a bumpy ride. Hopefully by the end of this year we’ll have a lot of that sorted out and things will be much smoother for our users.
July 18, 2011 at 11:26 pm
About the add-ons, we can consider that on a new FF version, very few add-ons will break, right ? Let’s say 10%, or even 20% at worse.
It feels a waste to disable 100% of the add-ons then.
Now why not allow all extensions by default, and keep a public black list of add-ons that don’t work ?
That BL could even be updated automatically very quickly most of the times, thanks to the community: ie. as soon as any user’s browser detects an incompatible add-on (like one that tries to use an obsolete API call), the browser automatically sends a message to mozilla’s server:
“Please add the extension foo to the black list for Firefox 5.3.8: foo tries to use obsolete function bar() in bar.js on line 23”.
As soon as it is done, other users updating their FF with foobar installed will get the message “foobar is not compatible with this version of FF”.
With this approach:
– very few users will experiment broken add-ons (those who happen to have updated FF before the public black list is updated by another user)
– users will be able to use most of their extensions right away
– you lower the burden on the add-on developers
Of course we can’t expose all of FF regular users to possibly bugged extensions, which may imply security problems or data loss (even if for a short period of time).
But if we restrict this approach to the FF beta / aurora users, and when “enough people” have used extension foo for “long enough”, declare foo compatible for the next release ?
July 18, 2011 at 11:59 pm
@Robert Kaiser – It’s not individual people who want LTS releases – it’s corporate IT departments. And that’s because large corporations are unbelievably risk-averse – seriously, if you’ve never worked for a client like a bank or telco or utility provider, it’s hard to appreciate.
But their view, put simply, is that when you change things, things break. Things breaking costs money – millions of dollars, if it’s something your international call center going offline for a day. And so changing things is something you do only when there’s no other possible alternative. They have *some* tolerance for patch updates (once they’ve reviewed the changes and performed extensive regression testing), but otherwise, they don’t change anything until it goes EOL.
July 19, 2011 at 1:20 am
Nice write-up. I can’t help but feel that the first problem (add-on compatibility) is a bigger problem than the second (LTS releases). I don’t hear people asking for Chrome LTS releases. Maybe it’s just because they’ve never had them.
July 19, 2011 at 2:47 am
Chrome also never had an extension API that included every internal interface.
July 19, 2011 at 3:28 am
Yep, part of the problem of importing Chrome’s release process (with adjustments) is that Firefox isn’t Chrome. Chrome was installed in a way to get around the initial UAC dialog, so promptless updating is easier; it only had the explicitly restricted extension mechanism, so their compatibility isn’t based off the application number.
Hopefully changes could come fast enough that there won’t be much permanent damage. Might involve cloning Rob Strong a few times, though…
July 19, 2011 at 5:28 am
Very perceptive post.
In reply to Asa: I can’t believe the rapid release cycle was started without first making updates silent?
I haven’t actually gone through the 4 to 5 upgrade myself since I’m on nightlies, but are you saying it is just as cumbersome to users as all previous major upgrades? I thought it had been made discrete. I thought that was the whole point of this …
July 19, 2011 at 6:01 am
Hum ….. JSCtype is advertize as the solution to circumvent xpcom’s issues with binary component. Do we plan to provide tools to migrate from a C++/xpcom to a C++/jsctype – some ala hydra/dehydra that would make all the heavy users of bninary components happy ?
July 19, 2011 at 6:05 am
One problem with the LTS is that some will develop their extensions for it and not for the latest Firefox. When asked, they will say: “We develop for the stable Firefox not for the unstable ones.”
Websites will have to limit their features to what the LTS provide. So the web will be held back by the LTS.
People using the latest Firefox will complain that extension are not ported and at the end we will be almost where we were before: the LTS being perceived as the real Firefox, the other release as beta named as release.
So I’m not convinced a LTS is the solution (except perhaps for people using XULRunner).
The main problem with the new process is that you can’t choose when to upgrade. Because of security fix. If a third-party extensions, web apps, web sites does break your left in the cold.
So we need some *overlapping*: we need at least one security update for each release, so that people who can will be on the latest/greatest Firefox and the other on the previous one (but as an X.0.1 with the security still there).
Therefore the end user will have 6 weeks to wait for an extension/web apps/websites to be adapted.
It holds back the web too, but only 6 weeks. And it gives back some time to the user to choose when to upgrade.
(And we also need to train extensions to write add-ons that don’t break each time; and also to provide the compatibility testing tools to authors that do not host their extensions on AMO)
July 19, 2011 at 6:53 am
Having a “stable” compatibility layer is oneof the goals of the Jetpack project.
Well, so it is, but:
AFAIK, the Jetpack SDK and API are Firefox-only. Any extension based on them won’t work in SeaMonkey, nor (IIUC) in Thunderbird.
The most powerful extensions (those which, as a user, I’ll likelove most cannot be implemented as Jetpacks anyway
Even when it is possible, converting a “traditional” extension to a Jetpack is a hasslePITA.
July 19, 2011 at 6:56 am
P.S. I’d like a “Preview” option on this blog. It omitted my unordered list, and forgot to strike out “like” before “love” and “hassle” before “PITA”.
July 19, 2011 at 8:51 am
Well articulated. Bravo!
You brought it together, discerned the relevant and made it coherent.
I dig that.
July 19, 2011 at 9:42 am
“I don’t hear people asking for Chrome LTS releases”
That’s because nobody goes near Chrome who has those requirements. Chrome users are end-users with light requirements. Chrome’s strength is its inflexibility in meeting a very targeted audience.
“When asked, they will say: “We develop for the stable Firefox not for the unstable ones.””
I’ve never seen this happen anywhere. Do you see people developing exclusively for Windows XP because it’s the ‘stable’ one and Windows 7 is the ‘unstable’ one? LTS does not create this mindset.
July 19, 2011 at 12:07 pm
@jono: Starting with Firefox 5, addons.mozilla.org checks add-ons compatible with the previous Firefox version for compatibility with the new one. Your friend’s extension was not compatible with Firefox 4, so it wasn’t tested. The problem with the switching to the rapid release cycle is that the tools for add-on developer hosting the add-ons on theirs own webspaces are afaik not yet released (because the people in charge had not enough time?). Restricting the API (like Jetpack does) is imho the wrong solution regarding competitiveness and the promise itself – at some point in the future, even compatibility for Jetpacks will break. Also, which of these popular add-ons could have been created with Jetpack? https://addons.mozilla.org/en-US/firefox/extensions/?sort=popular
@jor: Your suggestions has bad user experiences in its workflow. Also keep in mind that a blocklist can’t be updated on the client side every second (and disabling requires a restart for most add-ons).
@teoli: “Websites will have to limit their features to what the LTS provide. So the web will be held back by the LTS.” Not really, there are older browsers out there which lack new features like IE 8 which is supported until 2014.
July 19, 2011 at 12:10 pm
“Websites will have to limit their features to what the LTS provide. So the web will be held back by the LTS.”
No, websites have to limit their features to the intersection of features from the *worst* browsers used by any non-negligible proportion of their userbase. Which for most websites is IE6, which still has at least 5% market share according to most stats. (A 5% eyeball/customer increase is something many sites will gladly take.)
If, after supporting IE6, you have the time and budget to add shiny progressive enhancements for modern browsers, then adding one which can be used by IE7 and IE8 is probably your next biggest win, as it will likely work on FF2+, as well as Chrome, Opera, Safari and all other modern browsers.
If you want to add another enhancement that is only going to work on FF, good for you, but that is nowhere near what most websites are targetting.
July 19, 2011 at 12:12 pm
Doh!
s/work on FF, good for you/work on FF<latest>, good for you/
July 19, 2011 at 12:47 pm
“But like many big changes, it’s solved one big problem while creating two smaller problems.”
what is the problem that it solved? i don’t see why you guys coudn’t have integrated new features into firefox 3 and kept releasing 3.6.x updates. why did you bottle up a huge lot of updates for ff4? just for the grand revival of firefox or something? you yourself repeatedly say that version numbers don’t mean anything, then you say that changing the versioning scheme solved a big problem.
you created the problem, perhaps because you wanted ff4 to be the grandest browser launch ever, hoarding bug-fixes and new features. and then instead of accepting your mistake, you changed something utterly inconsequential. this shows disregard of your users’ intelligence and this is what has made me truly angry.
it makes me sad to say this, but ie9 is right now faster, more responsive, smaller and uses less memory and cpu than firefox 5.
imo, the best way to solve this mess is to bring in a couple of new guys, ask them to scrutinize your work, your methods and philosophy and accept their advice. maybe a third party will be better able to point out problems better than you guys yourself or the users (like me).
July 19, 2011 at 2:21 pm
Wishful thinking about developers using stable APIs doesn’t change the fact that extensions break with every release. Extensions are the only thing Firefox still has against Chrome, and now you’ve killed them.
I’m still using 3.6.18 because 5 or so of my extensions aren’t compatible with the new version. Did you not think about this before letting your marketing department take over the release schedule?
“But like many big changes, it’s solved one big problem while creating two smaller problems.”
What big problem did it solve? Catching up with Chrome’s bigger number?
July 19, 2011 at 2:33 pm
@Archaeopteryx:
“Your suggestions has bad user experiences in its workflow.”
Is that still a problem if we restrict this to beta testers ? Let’s say we:
– Let the early adopters (beta testers, users of the aurora channel…) have access to all of their extensions by default as soon as a new beta/aurora/… version is out (effectively ignoring the “maximum compatible version number”), _except_ if that given add-on is on the public black list
– When one of those users encounters a problem with one extension, update the public black list. I assume that most incompatibilities will be detectable automatically (ie. file.js uses an obsolete API call), but extensions can also be added to the BL manually if needed
– before a given beta version is becoming final, create a white list with all the add-ons that have been “sufficiently tested” (ie. enough beta testers using the add-on for enough time without problems being reported).
– the add-ons on that white list will be allowed by default for the users of the final version, and considered tested
That way we restrict potential bad user experiences to a minimum: as soon as an add-on is marked incompatible, further (beta) users will have it disabled by default (with the black list). So the effective number of people who will have that bad user experience is really small, and restricted to early adopters.
This even seems better than the current approach, where we rely on the extension developer to test her extension: add-ons will be tested by the community.
“Also keep in mind that a blocklist can’t be updated on the client side every second (and disabling requires a restart for most add-ons).”
We can just download/update the BL every hour (for example), and on Firefox start as well. If we limit this to early adopters, this will not stress the Mozilla servers too much.
Also, if we are lucky and the add-on uses the obsolete API call on initialization, then we can even detect it is bad as soon as the first Firefox with this extension starts. That means only the first beta user(s) with this extension installed will have to restart FF. For the next users the BL will already be updated, and their ext disabled by default.
July 19, 2011 at 4:03 pm
@jor: What about problems that affect only part of an add-on’s functionality? Let’s say two users with differents needs and workflows use that addon. They both notice the problem and report it through the Addon Compatibility Reporter. So far so good. But then one of them says: «Without that functionality, the extension is useless to me» and disables it, while the other says: «Even though that functionality is broken, the rest of the add-on works, and I cannot do without», so he makes sure the add-on remains enabled. Obviously a common blacklist won’t work for them both. (And the case is not fictitious: I’ve had in the past at least one half-broken extension which I intentionally kept enabled, until it became so broken that I had to disable it, so I went in search of a replacement and replaced it by four or five others.
July 19, 2011 at 5:05 pm
Hi Perry,
You said:
The problem was with our development process. Did you know that the version released as Firefox 4 – the one that took 14 months – was originally going to be Firefox 3.7? But more and more features kept getting loaded onto it, and our development process at the time said that the release had to wait until every one of those features was ready and every blocker bug had been closed. “bottling up a huge lot of updates for ff4” was a symptom of the problem. That’s exactly what we’re trying not to do anymore.
That’s not what I said. Changing the versioning scheme didn’t solve a problem. Changing the development process did.
That’s not why, but yes, we created the problem. And then we moved to the rapid release process to try to fix it.
Changing the development process was the result of accepting our mistake. And yes, the changes from 4.0 to 5.0 are very small. Nobody’s denying that. But the change in the development process was pretty consequential.
I’m sorry you’re angry, but I don’t understand what you think shows disregard of our users’ intelligence. Do you think we misrepresented what was going to change in Firefox 5? Yes, I can see that maybe we sent a mixed message by bumping the version number, but we tried to be as clear as possible about what was and wasn’t going to change in this version. Anybody who was paying attention would realize that a version in development for three months wouldn’t have more than three months worth of work in it. I don’t think anybody claimed it was going to be anything more than what it was. Do you disagree?
I’ll happily concede the point that it might have been better communication if we called it 4.1, or “Firefox June 2011 edition”, but that’s not what I’m here to argue about. My argument is that the rapid release process is the right way to go.
After all, this:
is what we need to focus on. And the rapid release process is a better way to fight that battle than the old monolithic release process was.
Angryface wrote:
Nope. Chrome doesn’t even use their version number in any of their marketing, and most users who are not web developers probably don’t know or care what version Chrome is on. We plan to stop using version numbers in Firefox marketing as well, since the version number will rapidly become meaningless with a new version coming out every 6 weeks. The big problem that it solved was, as I said above, the sluggishness of our development and release process.
July 19, 2011 at 5:11 pm
Well, I suppose you could just override the default behavior and enable a blacklisted add-on ?
Also if people report different information (add-on broken vs add-on working with a bug, for example), maybe we could have something like a (very basic) bug report system that would be set up for each add-on, and an admin (or the extension’s developer) would be able to chose what to do when a bug is reported: disable the extension completely, enable (with or without a warning) or ask the user.
The idea is to automatize as much as possible, but the defaults could be manually overriden of course.
July 19, 2011 at 5:15 pm
Hi Tony,
You said:
That’s a problem, I agree. It’s the reason Test Pilot isn’t implemented (yet) as a Jetpack, for instance.
But we’re working on it. There is a mechanism for extending the capabilities of Jetpack by writing shared libraries called modules. Thhe goal is to eventually make Jetpack able to do everything you can do with the old style of add-on. The community has already written many additional modules beyond what’s in the Add-on SDK: https://wiki.mozilla.org/Jetpack/Modules
I will poke around in the WordPress options and see if I can turn that on.
July 19, 2011 at 5:19 pm
Hi Jor,
I like your idea! The details need some working out but I think the basic concept is sound. Have you talked to the Add-Ons team about it? You can find them in #addons on irc.mozilla.org.
July 19, 2011 at 9:08 pm
@Teoli – an LTS doesn’t really hold anything back, because the people who use an LTS are those who don’t care much about the latest browser and web features, about add-ons, and so forth. All they want it something that works with their limited set of applications, and will keep working and remain supported for the long period of time before their executives decide to provide funds for “modernising” their IT systems…
July 19, 2011 at 10:00 pm
1. The add-on maximum version number is auto updated each time a new Firefox comes out.
2. The Add-on Compatibility Reporter sorts out the rest.
3. The new rapid release is the right move and will bring great rewards, we can’t let the naysayers win this one.
Yes these people are vocal but they don’t represent the majority of the Firefox user base.
July 19, 2011 at 10:39 pm
I think that Mozilla made the change of release pattern far too quickly. I can see how the new model seemed appealing, and with jetpack expansions, JSCtypes, etc., you do have ideas for lessening the extensions problem. But they’re not ready yet, and getting extension devs (those it’s possible to take with you) to change will take time.
Talking about a version-less Firefox just seems odd so soon after the FF4 glowing counter, worldwide publicity jamboree. Chrome can do it without criticism, they were like this from the beginning; that doesn’t mean Mozilla can get away with such radical change.
Re stability: when people commission web applications they typically want to agree what browsers will be supported. Thus far for me it’s been specific versions of IE and Firefox, maybe Safari too. Chrome, particularly, has been a best effort, no contract for a particular version type affair (even though it’s often used in development for the good debug tools). With Firefox going out of support every 6 weeks; it looks like Firefox is going the same way.
July 20, 2011 at 3:27 am
@jonoscript
“The community has already written many additional modules beyond what’s in the Add-on SDK: https://wiki.mozilla.org/Jetpack/Modules”
You do realize that the majority of these modules use either require(“chrome”) or require(“window-utils”) + some browser window magic and therefore are subject to the same breaking changes regular add-ons face?
Also currently the core Add-on SDK libraries are mostly not contained within the application, but shipped with the XPI. This then means that currently all JetPack add-ons are subject to the same breaking changes as regular add-ons. As soon as something breaks in an older SDK, you need to rebuild using a newer SDK that fixes stuff again and maybe even update third party libraries or worse hack third party libraries when no compatible version is around. If the author isn’t around to do the rebuild stuff anymore…
Other problems of the Add-on SDK were already mentioned before.
July 20, 2011 at 3:19 pm
The problem with rapid release cycle is not just for big companies. The success of Firefox comes also from people who make websites. We have spread Firefox among our users, our clients etc through our websites: “FF 3.6 is supported”, Get Firefox campains, SpreadFirefox and so on. Now how could we build an application and certify it for Firefox as it could change two times while we develop it? I don’t know how many web agencies could afford that. A LTS version could help: we could say to a client “FF LTS version X will surely work, we will fix problems with future releases”. We need a 100% tested version to give out as “trouble free”. I don’t know who can afford to test all the applications every few weeks.
July 21, 2011 at 11:13 pm
Hi Nils,
I talked to some of the Jetpack people today; they’re aware of the problem you describe. There’s just been a team re-organization to bring Jetpack inside the Engineering team which I hope will lead to a tighter integration with Firefox and shipping the libraries with the app. Really I think we ought to include the Jetpack libraries in core unit tests, so the tree will go orange if anybody changes a Firefox API without also changing the Jetpack library to match.
By the way, are you the developer of DownThemAll? I love that add-on; thanks for making it!
July 22, 2011 at 2:30 pm
Big fan of a rapid releases here, I’d like to point out two things.
I am a contributor of Army of Awesome, so I see a lot of tweets about Firefox. I notice that most people are surprised by the rapidly increasing version number, but aren’t negative nor positive about it. Most users don’t really seem to care.
Secondly, the rapid releases don’t create problems as this article suggests. Both the add-on problem and the I’m-a-school-IT-manager-and-don’t-like-updates problem pre-existed. The rapid releases only make those problems bigger. As this forces us to deal with these problems that have been around since the days of yore, this might actually be a good thing on the long run.
(Yes. I am an optimist.)
July 25, 2011 at 12:32 am
I think we need something like what Ubuntu does – every few releases is recognized as a “LTS” or “Long Term Support” release which is supported for much longer than a normal release with security updates, which would be good for corporate users or others requiring extreme stability and less change. However, we would still have the “normal” releases on the rapid cycle where the innovation occurs – these would be the releases that would be used by everyday users.
August 28, 2011 at 2:17 am
The rapid release can be a bit of a problem especially with the add-ons etc. As for the silent updater, i’m not a big fan of that and much prefer to manually update my software. If the silent update is to be added, at the very least it should be easy (for a non hardcore techy) to disable it.
September 19, 2011 at 8:54 pm
[…] cycle was way too slow for us to do that effectively; as Jono Xia describes in his blog post “It’s Not About the Version Numbers,” anything we did might not get out to end users for over a year. When David Baron fixed […]
October 15, 2011 at 2:40 am
…at the very least it should be easy (for a non hardcore techy) to disable it.
Doesn’t Firefox have checkboxes for that in the Preferences? (At least SeaMonkey has them.) And does one have to be a “hardcore techy” to check what the Preferences (or Options) menu offers? I wouldn’t think so, but maybe I’m a “hardcore techy” myself.
November 22, 2011 at 11:23 pm
A non-technical friend stopped using Firefox because he assumed it was full of bugs.
When I asked what gave him that impression he said it was the version number. Going from 3 to 7 in a short space of time gave him the impression each version was so full of bugs it became obsolete quickly.
I suggested it was mostly bug fixes, but his reply was that you don’t change the big number for a bug fix.
Seems the version numbers are not just meaningless.
When asked if he used Google Chrome he just laughed.
December 4, 2011 at 9:17 am
Next to extension compatibility and long-term support, you underestimated another important problem: perception. The perception that there is something wrong if you have so many major releases in a short timeframe. Sure, you can certainly convince someone technical who’s ready to take the time to understand the issue, but it’s not the majority of your “customers”. At the end of the day, you want your browser to be used.
December 8, 2011 at 3:47 am
Benoit, do you have data on that? We’ve actually conducted surveys and your claim that there’s a perception there’s something wrong with quick updates didn’t register among any of the concerns or complaints.
December 9, 2011 at 11:01 am
No data point for that. Obviously I would say, because, IMHO, the people filling in your surveys would fall into the category of “someone technical who’s ready to take the time to understand the issue”. See the sentence in my previous post: “Sure, you can certainly convince someone technical who’s ready to take the time to understand the issue, but it’s not the majority of your “customers”. Regards, B.
December 18, 2011 at 11:00 pm
If we had released the exact same thing but called it Firefox 4.1 would they have been happy
I suspect a lot of people would have been much happier.
Most of the time a ‘major upgrade’ is released when there are major, user affecting changes. Most people (who care at all) know that, and act accordingly.
Releasing a ‘major release’ to correct a typo in a comment is immensely frustrating, especially to people to have to do major testing to handle trivial upgrades just because of FF’s new numbering scheme.
January 2, 2012 at 12:45 am
What’s puzzling about this whole thing is that none of the issues that exist now or previously are anything new. Software development has been around for over 40 years and the needs have not changed all that much in the last ten. Users expect and require reliable software that evolves at a fair pace with the rest of the industry – end of story. Your move to rapid release was an awesome idea – but nothing new there and it should not have been a big deal if planned properly. It also did not require new numbering – that was a lame change – why you ask? Well first, as you pointed out, it can break things. Second, the user community is conditioned to relate major\minor numbers to mean a certain things – Mozila has now violated that with some still unknown numbering scheme.
Maybe you guys should have gone and solicited some advice from some successful software development folks – Apple comes to mind right away – and replicated what you could rather than re-invent something new that doesn’t work.
With all that said, it does appear Firefox is on the ropes and that Safari\Chrome has it squarely in the cross-hairs nearing pulling the trigger on the final shot. The Firefox dev team better get it together and I mean quick if they want a snowball’s chance in hell at being relevant.
January 10, 2012 at 6:05 pm
Someone said: What big problem did it solve? Catching up with Chrome’s bigger number?
Don’t forget IE!
Seriously, as a techy end-user who doesn’t develop Firefox addons, this is what Firefox looks like to me:
Firefox was amazing in the era of 1.0, 1.5, and 2.0, when I first started using it. A fast, small browser that could be changed in tons of ways by downloading “addons” to customize it any way you want.
Roughly around version 2.0, Opera was gaining popularity. It was a do-everything browser that didn’t need addons like Firefox for so much functionality. So Firefox adopted its model, and started packing in features in 3.0 – 3.6, not only making Firefox much more bloated, but making lots of addons redundant and making Firefox buggier (at least on linux – flash caused me no crashes in 2.0, but 3.0 would crash every day. 3.6 has stabilized again).
Once Firefox reached version 3.6, Google Chrome suddenly became the popular browser – largely due to its rapid-releases and rapidly increasing version numbers. And possibly due to the sudden realization that IE was also close to the double-digits, Firefox suddently decided to mimic Chrome with its rapidly increasing numbers.
Now, as for why I’m specifically still on 3.6? I have no clue at what version any of my addons will break. I use them all regularly, and have been unable to find an easy way to list the maximum versions all of them support.