Firefox Version Numbers: Cognitive Dissonance

Can anyone reconcile for me the following two opinions, both seemingly held strongly by the same people?

Opinion A) Version numbers for Firefox are now irrelevant. See our version-numberless marketing! Everyone will just be on “the latest version”. Soon, no-one will care about the numbers at all.

Opinion B) There is no possibility whatsoever that, instead of internally numbering the next releases of Firefox 5, 6, 7 and so on, we could number then 5.1, 5.2, 5.3 and 5.4. That’s totally out of the question – don’t even ask. It’s vital that we use this particular numbering scheme.

63 thoughts on “Firefox Version Numbers: Cognitive Dissonance

  1. So your proposed version numbering scheme is basically that version N be numbered as 5.(N-5)? So 5.1, 5.2, 5.3, …, 5.15, 5.20, … in perpetuity?

    This could definitely be done, but what’s the point of having that redundant “5.” up front?

  2. No, that’s not my proposal. If you want a concrete proposal, it is that we roll over the major version number every year – so Firefox 5 is for 2011, Firefox 6 for 2012, and so on. I feel that a general 0.1 increment better matches people’s historic expectations of Firefox numbering and the actual level of change in each release.

    But my point in this post is not that we should have a specific version numbering scheme, but that the people who are shouting “numbers are irrelevant” are also shouting “the numbers must be exactly this way”. And I don’t understand why.

    Gerv

  3. I think the people who are saying that version numbers are irrelevant are saying that therefore the numbering scheme we pick should be the one that’s simplest for us to do. And that would be the one that doesn’t require release automation changes, extension compatibility check changes, etc. That happens to be “increment by 1 every time”.

  4. I admit I’m not familiar with the technical details of our systems in this regard, but I find it difficult to imagine that, given that our last few releases were 3.0, 3.5, 3.6, 4.0, and various point releases thereof, it is much easier in the future to release 5, 6, 7 and 8 than it is to release 5.1, 5.2, 5.3 and 6.0.

    Or are people hoping they can write code which implements a “pick the next version number” algorithm rather than having a human define it, as now?

    Gerv

  5. Well, it’s not about version numbers, it’s about frozen interfaces.
    And frozen interfaces where sacked. Mozilla is creating somehting you
    can’t rely on.

  6. I think that (b) is really more along the lines of “version numbers are irrelevant, so there’s no point in spending any effort changing the numbering scheme.” Furthermore, any discussion of version numbers gives them additional weight, so if you are trying to downplay them, then discussing them further does not help that.

  7. Gerv, I can’t but agree with you. We’ve been criticised my many in the last 1/2 month for our new version numbering (and I’m one of these!), sometimes even covered with ridicoulous (maybe too much, but this is what we got).
    Having a more “human” version numbering honestly wolud look much more “professional” and FLOSS-style.
    According to Mozilla marketing common people shouldn’t care about version numbers anyway, while coming back to a more common version numbering would make the more skilled user and “people who cares about version number” in general happier. Plus side, people who say we’re just following Chrome in everything would have one less arrow in their arch.
    As gerv said, AMO and similar have lived quite happily (from what I know at least) untill now with number.* versions, so I don’t think that that will be a problem.

  8. Since you brought it up…

    I am a bit annoyed with the new version numbers too. Thunderbird jumped from 3 to 5 overnight. Firefox 4 lasted all of what? A month? (the Firefox 4 lasting such a short time bothers me more… usually I consider a product that scraps an entire version in that amount of time to mean it was a fatally flawed product that has been removed to avoid further embarrassment.) Of course, I do understand that Firefox 5 is pretty much Firefox 4.1.

    Had anybody consulted me (LOL) I would have made the versioning changes a little less drastic and instead done something along the lines of what Microsoft did with Windows XP or Vista (that is to say, hide the versioning scheme from the public and have marketing come up with a fancy name that keeps them out of your sandbox)

  9. First of all, I think you’re mis-characterizing how this happened. No one has ever said that there was absolutely no way that we’d ever consider using 0.x numbering — or “don’t even ask.” We did consider that. We considered all kinds of versioning schemes. We posted and had public phonecalls discussing this for weeks. After lots of discussion we decided for one numbering system and against a bunch of others. Setting up the question as you have isn’t particularly fair to the people who put this new system together.

    Second, we picked whole numbers for a pretty compelling, IMO, reason, because we thought it was the easiest way to communicate the most accurate information to the audience that we were targeting — the Mozilla project including add-on authors.

    We have and we will break add-on API compatibility with every release, certainly binary add-on compat. We will be adding major new features or doing serious re-architecuring with every release. See Azure landing in 7. See Type Inference in JS landing in 8. E10s will land in one of these updates before long.

    We’re making serious changes every 18 weeks that dramatically impact that “internal” audience. I think it would be a lie to the call those kinds of changes minor updates. We’d be telling add-on authors and Mozilla developers that these are minor changes and they’re just not.

    Taking a couple dozen security and stability fixes every 5 or 6 weeks is a minor update. Landing new architectures that break add-ons and potentially the web (yeah, we need to consider that with these releases and we need testing to prove we haven’t broken the Web) is not a minor change.

    Our 18 weeks dev cycles now are seeing more than 2000 change sets each, including major architectural changes. I don’t think those are minor updates at all.

    But I want to loop back around to the first point again because I think it’s important. You are setting this question up to make the people who participated in the planning of this new system into unreasonable assholes who refused to consider something so obvious. That’s not really fair because it was suggested and it was considered. It was also rejected.

    – A

  10. “If you want a concrete proposal, it is that we roll over the major version number every year – so Firefox 5 is for 2011, Firefox 6 for 2012, and so on”

    +1 and several more +1’s for anyone too lazy to leave a comment. :)

  11. If I remember (I do;) the hype with Fx4.0, the fireworks, the glow, the climax, I feel suckered in. But then “every minute a sucker is born”.

    You can be sure however I will not travel to Lourdes, Fatima, Medjugorje the next time a major release is advertized. I will not fall on my knees direction of Mountainview. Instead, I will just politely ask:”Dudes, what’s the big deal?”

  12. Gerv, I have one quick question. You’re advocating moving to a 0.x model for each of our 18 week cycles. To what purpose? For what audience?

    – A

  13. smo, the measure for whether a release is a big deal is the comparison with what came before it. So 4.0 was a big deal. To say that the rapid release cycle implies that it wasn’t is an anachronism.

  14. First of all, I think you’re mis-characterizing how this happened. No one has ever said that there was absolutely no way that we’d ever consider using 0.x numbering — or “don’t even ask.”

    That’s the message I’ve been getting from you, in reading your interactions with people trying to advocate for change in the newsgroups. I’m very happy to admit that not everyone holds this opinion that strongly.

    We have and we will break add-on API compatibility with every release, certainly binary add-on compat. We will be adding major new features or doing serious re-architecuring with every release.

    As we have with .x releases in the past. Heck, we’ve done it with .n.x releases as well on at least one famous occasion.

    I don’t buy the argument that incrementing the major version number is the only way we could signal release-to-release breakage.

    You are setting this question up to make the people who participated in the planning of this new system into unreasonable assholes who refused to consider something so obvious.

    I strongly refute that. I am suggesting that people who hold both of the opinions above at once strongly are holding two dissonant views. It may well be true that many people hold only one of them strongly, and the other not very strongly. Or they hold neither. And “unreasonable assholes” is your words, not mine.

    Gerv, I have one quick question. You’re advocating moving to a 0.x model for each of our 18 week cycles. To what purpose? For what audience?

    As shaver said in the newsgroup (and that’s what prompted me to actually write this thought down), lots of people seem to care. You may say they care unreasonably. You may think it’s stupid to object to big version number changes, when they should be looking at the size of the actual changes. But I think we’d have got half as much negative publicity around the new release model (which was enormously harmful, both as negative publicity and because it obscured the important positive message) if we’d adopted the scheme I mentioned in one of the comments above – one new major version number per year. And did everything else the same.

    The version number changes became half the story. That’s just bad.

  15. Some of the negative publicity was about the support mozilla offers to old versions.

    Why are there no LTS (long term support) versions?

  16. Versions 5 and 6 could have been released as 4.1 and 4.2, nobody would have raised a question. At the same time, landing Azure and Type Inference would have warranted a 5.0 release, the same goes for Electrolysis (enabled by default) or major UI changes. Mozilla is attracting criticism because it went for whole number versioning. Don’t tell us product managers have no idea what is under development for the next 3 months. You could always assign a major number when anything major lands.

  17. FYI – in Chrome we use every field in the version number to mean something specific:

    14.0.803.0

    14 = major version, 14th stable branch (or trunk to become 14th stable branch within next 6 weeks)
    0 = minor version, 0th branch from stable branch. We have only ever used this once, for 4.1, when we decided to make significant changes to an existing stable branch. That was back when we did 4 releases per year, I doubt we’ll have to do this now we’re on a faster cycle.
    803 = build #. 803rd official build since we had something that would compile and run (back in 2006… sheesh has it been 5 years already?!). This happens roughly daily now.
    0 = patch #. This number is incremented any time we have to kick off an additional build, for example to fix an issue that comes up and it’s simple enough to respin rather than waiting for the next automated daily.
    (Thanks to Anthony for clarifying this again to me recently).

    By design, this number has no marketing input or impact. There is no haziness or room for discussion about when it increments – changes are driven by regular branching and build actions. Any discussion is guided by well articulated process. This means that things are very clear to every aspect of the release pipeline from engineering and product through the release engineering that pushes the bits. We have some slop to handle the unexpected but in general have found that having a well defined process and sticking to it makes it easier for everyone to understand.

    As for the version number – you should be able to parse a Chrome version number and obtain each of the above four bits of information above from it. This wasn’t always an easily understood when we were establishing this practice based on past expectations of desktop software, but the result has been a more predictable system that we’re all pretty comfortable with now.

  18. Quote: Some of the negative publicity was about the support mozilla offers to old versions.

    Some of the negative publicity was also about the manner in which that news was announced.

  19. “Some of the negative publicity was about the support mozilla offers to old versions.”

    “Some of the negative publicity was also about the manner in which that news was announced.”

    I thought that it was because the Google Toolbar wasn’t compatible with the newest version of Firefox. :)

    In the old days, I would have just said wasn’t compatible with 5.0.

  20. mucinch: “You could always assign a major number when anything major lands.”

    That is one of the primary arguments for not doing it. Stuff may un-land at any point up until a few days before the release. So if you tie the numbering to features, that means nobody can be certain of the version number until a week or so before the release, which means you might either have 6.3 alpha becoming 7.0, or 7.0 beta suddenly becoming 6.4 (or you have to change the release timing so your major feature lands in the version you thought it was going to, instead of having a fixed schedule).

    For those talking about Chrome, from the discussions I’ve seen, lots of the people complaining about the new Firefox numbering think the Chrome numbering sucks as well (not to mention the fact that you apparently have to edit the registry to stop Chrome from updating silently).

    Gerv: “I think we’d have got half as much negative publicity around the new release model … if we’d adopted the scheme I mentioned in one of the comments above”

    My guess would be that there would have been more than half left. The negative publicity was, I think, mainly associated with the change in release and support schedule itself, and the (lack of) communication and understanding around it until it actually happened. If every version was a .1 increment, some of the complaining would be deferred until the a big change broke stuff.

    There were a lot of complaints about 3.6.4 (IIRC) with OOPP, and most of the more conservative types were probably still on 3.5 at that point anyway, and the new feature addition could be turned off with a pref.

    In terms of reducing negative publicity, not having the Firefox product manager saying that Mozilla shouldn’t care about enterprise users would have been an easier thing to achieve than changing the version numbering after it was decided…

  21. Log time Firefox user here.

    Where I am seeing a problem with the whole number versioning is in a mailing list for people who support Blackboard, an web-based course etc. application that is much used in North America. When people spend weeks ensuring that the newest Service Pack of the application doesn’t break anything on the browsers the university uses, having the browser add ONE to the version number every 18(?) weeks is SCARY.

    I don’t think Mozilla is doing itself any favors with this audience. Firefox may no longer seem as safe a choice.

    Me, I run mostly live with Aurora and love it–I like the new pace but I’m fine with numbers on either side of the decimal point.

    TDT

  22. Ben: Thanks for dropping by :-) Are you saying that you think all of this fuss will just settle down, as people get used to our new system? You may be right. I hope you are.

    Michael: you might be right about the spread. But even if there were no less negative publicity and it were more spread out, it would have been better. And we’d have time to react, adapt, document and explain more.

    As for your last para, well, yes.

  23. Gerv, when I asked for what purpose and for what audience, you put a lot of emphasis on publicity. Our PR team and our Marketing team are happy with the current system and they’re the ones on the front lines of “publicity”. Also, that negative publicity has already happened. It’s in the past. It may happen to a much lesser degree with 6 and probably even less with 7 and eventually it goes away as the version number disappearing act finishes. I don’t think the concern about future negative publicity (which I assert is diminishing over time) is reason enough to change the scheme to something that is is less accurate for our development community and add-on developers and that would push another disruption into a new development model which is happily chugging away on Firefox 8 already.

  24. Er, have you noticed some of the public discussion? It’s mostly irrational, I think, but irrational people can be noisy and influential. And negative.

    You know the arguments, or at least you’d better.

    1. Enterprise: “We just installed version 3, it will take us 36 months to test all our crapware on version 4. And we can’t get security updates for it because it will take another 24 months to test version 5 before we will let our minions have it.”

    2. Users: “All my extensions are broken. I’m going back to version 2.”

    They’re wrong, I guess, but public perception is kind of important. If you want, you can waste a lot of time changing the rest of the world. I can’t imagine why it was done.

    I hear you want rapid releases, with smaller, incremental changes. That’s fine, but do you really have to speed up the version clock to do that? I have to admit, I sort of like the system Ben Goodger described.

  25. Version numbers are important, but they must also be manageable for both short terms needs (important fixes) and long term needs (expectations that there won’t be surprises, think enterprise users).

    But since Firefox 4, it’s now completely hard and irrelevant to ask a user or a client to use and test Firefox with a specific number. Most of the time, there a no changes that warrants a user to upgrade to version 5, 6 or 7 for that matter. The UI is no different, new features are too few to track and furthermore, we loose the ability to remember which version number incorporates the new feature that we would like or developer to use and our users/clients to play with.

    In a sense, the new versioning of Firefox is like a large cloud where you don’t know what you will find once the cloud clears.

    I have stopped promoting Firefox since when it was discontinued a few weeks after it’s release. I know that Firefox 5 and 6 are in fact Firefox 4 in disguise, but for most users, this is confusing.

    Please bring in back sanity and long term set of features that are easy to relate to.

  26. @Gerv: I think Boris was talking about changing the versioning scheme *now*. And it would definitely be hard to rename Firefox 8 into Firefox 5.3 at this point. One might of course speculate what would have been if some decision were made half a year ago – but that’s indeed unfair. It was a reasonable assumption to think that people didn’t care about version numbers too much, lots of people turned out unreasonable however.

    @Asa: Please excuse me if I sound unfriendly – but you are talking lots of bullshit lately. I’m not used to having an “I don’t buy it” reaction when a Mozilla representative speaks up but your argumentation is strange to say the least. There are certainly valid reasons why the current versioning scheme was chosen (Michael and Boris mentioned some), I am certain that people who make the decision had good reasons. But it doesn’t help if you list reasons that are obviously bogus.

    Mozilla *never* changed the second digit for minor updates, a change in the second digit was always a major update – like Firefox 3.6. As an add-on developer I know very well how many things changed under the hood even though end users probably didn’t notice much (hence the 0.1 increment). So why was a 0.1 increment back then in line with everybody’s expectation and suddenly a dangerous miscommunication now?

  27. I think version numbers are far from irrelevant for Firefox. The simple fact of the matter is, is that any major version will break the majority of add-ons. If you look at the current add-on library, all the add-ons that have been uploaded and what works on the current stable release, you’re in a minority.

    Firefox needs to cater to it’s audience and despite what people in marketing may feel, it’s far better from Mozilla’s point of view to be able to give an audience “ooh moments” rather than not. Those “ooh moments” are what build the buzz, they’re what makes you proud to tell your friends to try the new version or makes you proud to tell your friends who are in love with Chrome to give Firefox another chance.

    Chrome is backed by the biggest advertising company in the world. They market their browser aggressively in print, on their services, on TV and elsewhere. How does Firefox expect to compete with that? How does Firefox expect to maintain market share if there’s nothing to market? If people can’t use word of mouth in those moments where a new Chrome advert is seen. You know the “oh a Chrome ad, have you tried the latest Firefox?” “Why didn’t you like it? You should try version Six, a lot has changed, some noticeable UI tweaks but overall it’s a lot faster. Download it and let me know what you think”.

    I cannot understand why when given that Mozilla doesn’t have a huge reach in terms of advertising that Mozilla would willingly give up on it’s greatest asset, it’s users enthusiasm. I know I never saw a single tweet on my timeline about the release of Firefox 5 other than those that moaned it wasn’t worth a version bump.

    Version numbers may be irrelevant in the grand scheme of things but they are at least for now, the crutch that enables the fans to cheer loud and proud and tell people what’s great about something they love.

    Firefox 7 should be Firefox 4.5 at best and with Firefox 8 (current mozilla-central/trunk) looking like it could get some experience changing landings, that should be Firefox 5.

  28. Meaningless version numbers are an aspiration not a reality, in the meantime for the large share that do care about version numbers, marketing says they shouldn’t see a number significantly less than other browsers’.

    Not that I like the idea, but I understand the rationale. I also wonder what is the harm in having whole dotless versions.

  29. FWIW, I think the most important parts of the new versioning scheme are that the version number is locked on m-c when the previous m-c train moves to Aurora and that the Firefox and Gecko numbers are the same.

    The current train is 8, so at this point, I think it’s not worthwhile to change the versioning scheme anymore. Enough trains have already left m-c with the current scheme. By the time the train now to be called 9 starts, people will have gotten used to the current scheme.

  30. They’re schedule-driven releases, so make it explicit. 2011.4 for the 4th Firefox release of 2011. It’s associated with time without being a date, it de-emphasizes major/minor (there would no 2012.0 release), it doesn’t lead to “Firefox 42″ which some find ridiculous, it makes no claims about whether a release has big features or not.

    (Is there a Paypal donate button or Amazon wishlist for a curated set of self-improvement books for Mr. Dotzler? Starting with http://en.wikipedia.org/wiki/How_to_Win_Friends_and_Influence_People )

  31. tl dr the comments.

    As I understand it 1 applies to marketing, and 2 applies to development. The inevitable question with 5.x numbers is when to switch to 6.0, and that’s the sort of pointless debate that round numbers solves.

  32. To actually answer your slightly provocative question: Did anyone actually hold both opinions A + B at the time the decision was being made? If not, and there seems to be people claiming it’s not true, then the real issue is that there appears to be a bunch of people who don’t understand the new system. There are, for example, relatively technical people on the Hacker News forum, who on hearing about new features in Firefox 8, wonder why Mozilla skipped 6 and 7.

    Of course they haven’t been skipped, they’re already part way through the process of being released. But someone who was unaware that this process was already in motion might think the time is right for discussions about what the numbering scheme should be, when obviously that time was a few months ago. If the discussion happens anyway it’s going to be unproductive for both sides with one feeling ignored and the other feeling like their being unproductively trolled.

  33. The new FF numbering/release scheme is complete bullshit: As an experienced sw developer you simply know that you can not provide new major releases every six or eight weeks, except you omit all testing. For the numbering: As a consumer I still can not see the major new feature of FF 7.0 over FF 4.0: It looks the same, feels the same, so what’s the difference? Why was version 4.0 skipped for TB?

    As I see it now Mozilla has traded in all of its own identity for an identity as a copy-cat of Google Chrome and MS IE. But: Why should I go with the copy if I could get the original for free???

  34. “If the discussion happens anyway it’s going to be unproductive for both sides with one feeling ignored and the other feeling like their being unproductively trolled”

    Apparently, some already feel the ways that you mentioned and so that is why this discussion is happening now despite the fact that this is an older topic.

    I don’t see the negative feedback and/or criticism fading out anytime soon from the media, users and probably a good amount of add-on developers.

    For users, when their favorite add-on(s) become incompatible, or there’s a new feature that they don’t like, they have an easy way to revert back. Just reinstall the previous version. So they’re not using the latest version, but at least their still a Firefox user. It’s going to be harder for them to locate that in the future let alone what version they’ve just been upgraded to especially since Firefox won’t be promoted with a version number. Not even the first run page (isn’t now I think). People will just get pissed and try another browser and who can afford that right now.

    As far as add-on developers, they left in droves before Fx 4 was released and more are currently abandoning their add-ons (since 5.0) because of the accelerated pace of things and its end users that suffer and are getting pissed not to mention losing great Mozilla contributors. It’s more than the usual incompatibility complaints. It’s in far greater numbers.

    When all is said and done, I sure hope that people will remain civil here and that this doesn’t cause any greater fracturing than it already has.

    It’s hard to keep up with all that is going on with/within Mozilla. It’s actually near impossible, so understand that this is all new to a lot of people.

  35. Drop the incremental versions entirely and go for an Ubuntu like versioning scheme where versions are year DOT month. It sets the expectations correctly on the life time of a release and also how far behind you are. Basically Firefox 3.0 sounds pretty good since 4.0 was released fairly recently. That is until you realize that it is actually the same as Firefox 08.06 in the ubuntu style notation. I.e. a bit more than 3 years old: time to upgrade, obviously.

  36. We have and we will break add-on API compatibility with every release, certainly binary add-on compat

    I miss words to really describe what I feel reading this. My late Wengo for
    Firefox add-on was based on a huge set of binary libs, and I did it for the VoIP
    division of a major telecom company here in France. They would _never_ have
    done that add-on with a mandatory recurrent update/rebuild/reship six weeks
    process.

    Harming add-ons every six weeks, while add-ons are *the* major plus Fx has
    over other browsers, seems to me – enough politically correct – just plain
    crazy.

  37. By the way, it is possible for Firefox to switch to a year.month system. It could start with version 12 next year. 12.09 if it’s to be released in September. But at this point, there’s nothing to stop version 9 coming right after version 8. It’s already too late to stop version 8.

  38. I don’t really care about version numbers, but having add-ons break every few weeks means that we have to choose if we want add-ons *or* security updates. We can’t use the version number any more as an indicator of what’s safe to upgrade to.

    I get the sense that this is what has people so upset, not whether the next one is a 5.1 or an 8.0.

    If add-ons break randomly every few weeks, effectively FF no longer has add-ons.

    Which removes one of the major features over other browsers, for me.

    Give us an “LTS” every couple of years, or *some* way of knowing that tomorrow, after a security update, I can still use Selenium IDE, or Firebug (for example).

    This isn’t about “enterprise”, it’s about being able to use a piece of software today for what it was used for yesterday.

  39. > There are, for example, relatively technical people on the Hacker News forum, who on hearing about new features in Firefox 8, wonder why Mozilla skipped 6 and 7.

    There are countless occasions under which even technical people are lost. We have a typical example coming now, with 5.0.1 being released to fix a Mac issue with the upcoming OSX Lion. 5.0.1 was also released for Windows and Linux mostly because of our release machinery, but won’t be given as an automatic update. I can tell you that for sure some Windows and Linux users (even power users) will complain about not getting that update.

    The problem is not directly the people, but mostly communication. On the other hand writing “the Firefox development that will eventually become Firefox 8, but there will still be 6 & 7 before that” is not exactly nice to put in a headline.

  40. Looks like this thread is growing faster than I can read. Sorry for not arriving the very hour it started and not staying glued to it since then.

    Asa said yesterday (or maybe the day before depending on timezone: 2011-07-11 16:57) “we’re making serious changes every 18 weeks”. But under the new system, there’s a new release every _six_ weeks.

    So why not number them 4.0, 4.3, 4.6, 5.0, 5.3, 5.6, 6.0, 6.3, 6.6? Then 4.0, 5.0, 6.0 would be those “serious changes every 18 weeks” and the .3 and .6 would be the “less serious” changes in between? With, of course, 5.6.1 or 6.3.2 etc. if there happens to be a party-crashing stop-press fix that cannot wait for the next sesquimestrial maturity date.

  41. @Colin Coghill:
    Yes indeed, and there is one particular very popular and useful add-on for Thunderbird and SeaMonkey, namely the “Lightning” Calendar extension, which includes a binary XPCOM shared library. So willy-nilly, if that add-on’s overworked team is not ready in time, or wants, as just happened, to “temporarily stop builders in order to avoid problems with the release”, it’s the choice you mentioned, especially for those users who surf on the crest of the wave (“nightly testers”, “trunk users”, call us what you want): either don’t get the available nightly of the application, or temporarily disable the Calendar extension and unmothball a copy of the self-standing Sunbird calendar program, which hasn’t been updated since 25 May 2010 and never again will be. And this every month and a half. (The same happened during the “Great XPCOM breakage” more or less concomitant with Release 4 and the complete overhaul of the add-on manager, when at least two thirds of the add-ons I use stopped functioning overnight, and Lightning for several mmonths. At least this time, between 7.0 and 8.0, they were better prepared.)

  42. Asa said: Our PR team and our Marketing team are happy with the current system and they’re the ones on the front lines of “publicity”.

    That is one of the most depressing things I’ve seen you write in a long time. It’s exactly the sort of response one employee of an ordinary company would give to another one, and it’s entirely un-Mozilla. Our community of thousands of loyal fans should be on the front lines of publicity! That’s how we got to 400 million users. It wasn’t by putting up ads in a railway station in San Francisco. And the comments here and in other places show that a lot of our community are confused, frustrated and disillusioned with what has happened recently.

    The seemingly-rapidly-spreading idea that what happens inside MoCo is what matters, and only the MoCo team involved in any particular activity are doing anything useful, is a sure way for us to lose our community and get outgunned by companies 10 to 100 times our size.

  43. The rapid release circle creates a lot of undesired side-effects for add-on authors and by this for add-on users, of which there are many…
    From what I gathered that what most users actually criticize, and not the version numbering itself.

    I’m a somewhat successful add-on author myself, incl. add-ons that contain binary components that cannot migrated to ctypes, and am currently thinking about abandoning some of my add-ons because one application version each 6 weeks is simply too much to handle even with the amo-validator auto-testing for compat issues and auto-bumping the maxVersion if there are none.

    My proposal:

    Keep the platform stable for at least 4 releases (24 weeks, 6 months)!

    • During the stable period add as many new features and bug fixes as you want, but generally do not include breaking changes, i.e. ship a compatibility layer if you have to or postpone stuff where there is no compat layer possible or feasible.
    • Also do not break binary compatibility. That worked before and I don’t see a reason why it would not work now. It creates a little more work for mozilla devs, but those can usually better cope with a little more paid work than the army of awesome hobbyist add-on developers can.
    • Breaking changes of course also covers the web ;)
    • Number the releases accordingly, e.g 6.0, 6.1 and so on.
    • Add-ons would then still ship with a maxVersion of 6.*

    After those 4 releases or 6 months it’s time for the next major version, which of course is then allowed to contain breaking changes.

    That way add-on authors will be far more happy and (add-on) users even more. And lets not forget about the XUL application developers (in-house or third-party) and the few remaining embedders…

  44. I believe everybody out there wants an LTS release: end-users who want to keep their addons running, corporate users who can’t validate their apps continuously, and XUL developers who want to spend more time coding than matching the platform. The latter is what bothers me most but I’m certainly biased here.

    There’s no point in trying to compete with Microsoft’s 10+ year support for corporate environments: a 60-week LTS support would be great, a 6-month LTS support could be enough. *If* we had the resource to maintain such an LTS branch, the classical version numbering would make sense (as Nils and others have suggested).

    If we can’t afford such an LTS branch I’d be curious to know why we’re not using a time-based numbering system (we could switch to 12.0, 12.1, 12.2… for Firefox 12 and start with 13.0 in 2013). Asa writes that it’s been debated and rejected; but as it is now quite obvious that the version numbering confuses many (if not most) users, maybe those arguments could be re-evaluated?

    A “better” version numbering would not solve the issues that are related to the lack of an LTS branch, but it looks like an easy way to avoid many of the critics that Firefox is getting since Fx5.

  45. That is one of the most depressing things I’ve seen you write in a long time. It’s exactly the sort of response one employee of an ordinary company would give to another one, and it’s entirely un-Mozilla. Our community of thousands of loyal fans should be on the front lines of publicity! That’s how we got to 400 million users. It wasn’t by putting up ads in a railway station in San Francisco. And the comments here and in other places show that a lot of our community are confused, frustrated and disillusioned with what has happened recently.

    The seemingly-rapidly-spreading idea that what happens inside MoCo is what matters, and only the MoCo team involved in any particular activity are doing anything useful, is a sure way for us to lose our community and get outgunned by companies 10 to 100 times our size.

    Gerv, if you were a girl and lived more near me, I’d have kissed you. I couldn’t have said that better (and I’ve tried to, with an entire blog post). And it’s not just Asa, many employees are developing a company-mentality, which should be avoided as a “worst enemy” inside Mozilla. And of course I share your vision of who’s the true marketing team of Mozilla.

    @Nils Maier: your proposal seems quite nice.

  46. > We will be adding major new features or doing
    > serious re-architecuring with every release.

    This. This right here is why I have permanently lost interest in upgrading Firefox. This is why I downgraded back to 2.0.0.20 — because it is the last version that was reasonably stable — in terms of not crashing, more importantly in terms of not losing data, and also in terms of the feature set and UI being well thought through and coherent with no bizarre new “we just thought of this really interesting way to be totally gratuitously different from all user expectations” nonsense.

    I do wish I could get the Gecko improvements backported.

  47. > lots of people seem to care. You may say they care unreasonably

    It is a well-established fact that a lot of users care way more about software version numbers than is reasonable.

    However, while I do think that the extremely short lifespan of Firefox 4 was a little odd, it is not the version numbers that worry me most about this new Firefox development scheme. I am concerned that I will eventually have to switch to some other browser entirely, probably one that’s not as good as Firefox was, because Firefox is actively destroying itself, and the old, stable version that I’m using will eventually cease to be useful on the modern web.

    I won’t be able to use 2.0.0.20 forever. I’m not sure which lack-of-feature will be the killer, but if I had to guess I’d say inline-block is a likely sticking point, as that tends to break layouts when a site relies on it and the browser can’t deliver. Maybe it’ll be media queries or something else. Whatever it ends up being, I’d *like* to see the Firefox team come out with something new that I can use to replace it, but the way things are going now I have almost entirely lost hope that that could ever happen. I’m afraid I may eventually have to settle for something less in the UI department, in order to get a modern rendering engine. I may have to switch to Opera or, heaven help me, Chrome. I don’t want to do that. I don’t like them. They suck. But they can render useful CSS properties that Firefox 2 can’t…

    The other option is to try to use a recent version of Firefox, but I’d have to give up some things that are very important to my web experience, perhaps most notably the regular use of bookmarked tabsets (which are severely broken since 3.0 in a way that causes data loss — apparently they’re going to stay that way, because the Firefox team has lost interest in fixing bugs, because they’d rather pointlessly “rearchitecture” the UI to death).

  48. I’m so happy about the new version scheme because it’s supposed to eliminate those dumb discussion about if a 6-week set of changes is now a “major” or “minor” version. Please don’t reopen that dumb discussion (and sorry for my choosing of words, but it’s how I think about it).

    And you’re wrong in that “no-one” should care about version numbers in the future, nobody has said that. It’s _users_ who shouldn’t care, but _developers_ still need to.

  49. The shifting (or rather, nonexistent) API has always been a sore point for users. Apparently, now it’s worse. If you can’t nail down an API very soon, you simply have to stop changing things, unless you like losing users. That’s the reality.

  50. Users care because they encounter a “These add-ons of yours are incompatible with the new version you just thought you would painlessly update to” message — every 6 weeks. This is annoying at best and to the non-savvy, worrying.

    Maybe this will get better over time. Some add-ons will simply disappear (not neccessarily a problem). I sincerely hope it won’t turn too many people off Firefox in the interim.

    The real problem here seems to be a massive and continuing failure of communication on Mozilla’s part. Communication with the community in particular. This transition could have been so much smoother.

    In retrospect it was probably a bad idea to have a huge campaign for Firefox *4* and then declare it obsolete a minute or two later. Much cleverer to have called it “Firefox Z” or whatever, to signal the move away from version numbers.

  51. Just to add one more example: What is an unproficient user to do when he encounters a “These add-ons are incompatible” message? He is given no help whatsoever. There is no

    – explanation that the add-on might be updated soon, so this is could be a transitory problem

    – message that the problem has been noted and passed on to the add-on author

    – explanation that reinstalling the previous version is a bad idea (no security fixes)

    – option to turn off compatibility checking by installing the requisite add-on (not even in Aurora builds!)

    – in particular, no hint of a practicable workaround for the user who happens to depend on some add-on.

  52. In all fairness, add-ons are checked for compatibility when a user decides to update/upgrade Firefox and Thunderbird (not sure about SeaMonkey) and presented with a list that won’t be compatible with the version that they are about to update to. They then have a choice not to upgrade. After updating, they are presented with the list again and offered an option to check for updates of those add-ons. That’s usually in vain, because even if the add-on developers have updated their add-ons, they may not have yet been reviewed yet by AMO editors.

    Developers of the most popular add-ons are usually (but not always) ahead of the game and have had their add-ons ready prior to the next major release. In fact, preparing for the next update or upgrade is usually what they’re doing as soon as they’ve gotten compatibility with the next release squared away.

    Add-on compatibility issues has always been a gripe with end users. It’s nothing new at all. The thing is, now add-ons are becoming incompatible, unusable, and abandoned at a much more rapid pace and higher volume.
    Add-on developers can’t keep up with the fast pace.
    Nearly all of them develop add-ons without any monetary compensation in their spare time between their paying jobs, family lives, etc.
    The days of setting a max version number and knowing that you have time to prepare for the next release are over. Despite AMO’s new (automated?) compatibility screening.

    This is by no means a conspiracy theory, it’s a fact that XUL based add-ons are being pushed out in favor of Jetpack type restartless add-ons that are intended to break less with new releases. There has been ample notice and posts about it although not enough examples and documentation imo, plus changing the interface with the new method is too much trouble and work.
    It’s just now, the rapid release schedule and the squeeze on XUL add-ons all makes sense. To me at least.

    When it all comes down to it, I just feel that not a single end user, or Mozilla contributor can be spared right now. Chrome isn’t going anywhere, it’s right on our butts. And it will surpass Firefox in market share in some locales soon if it already hasn’t.

    I care as an end user what is going on with my Firefox. I care as an add-ons developer hack. I care as an internet user what happens to the web and Google and Microsoft don’t have my best interest in mind. Mozilla does. So Firefox has to remain relevant and not become an “alternative” browser again. It drives Mozilla’s mission. Firefox cannot become a SeaMonkey used by a very particular type of user.
    Not a dig against SeaMonkey. I love it.

    So whether it be solid legitimate issues, or just perception, whatever it is, we need to get it together. A fractured, unhappy, community and confused user base will crumble.

  53. @Ken Saunders: Starting with SeaMonkey 2.0, the add-ons subsystem is identical with that of corresponding versions (by Gecko version) of Firefox and Thunderbird. And many extensions work in two or three of them, though not as many as could be (extension authors often “forget” that SeaMonkey exists, and so don’t write a section for it with minVersion and maxVersion).

  54. @Ken: “They then have a choice not to upgrade.” — this is no longer true as you would be using an insecure version. The whole rapid release concept only works for users if it is essentially invisible. This is why you don’t have the same volume of complaints for Chrome.

    I am actually in favour of the rapid release cycle. But how it has been communicated and prepared for outside Mozilla (within the add-on developer community in particular) does not seem to have quite worked.

  55. Pff… versioning, persioning…
    Let’s say the minor- and major-versioning was feature-oriented, then there would be bikesheding in the form of endless discussion about which feature justifies a major and which just minor version bump (e.g. should rather user-facingness or add-on compatibility matter? Are performance improvements user-facing? yadda yadda). And with a release model that’s clearly NOT feature-oriented this wouldn’t make much sense.
    Or let’s say the versioning would be used to encode information about it’s release date (it probaly would have to be a hybrid model because of the possibility of chemspills) then what would the average user gain? Since with the current release model there is only 1 (in words: one) non-obsolete stable version who would talk about older versions anyway?

  56. “this is no longer true as you would be using an insecure version.”
    Good point that I missed.

    About your other one. I would not at all be comfortable with silent updates.

  57. I thank God for Firefox as it is the best! IE8 and Chrome does not even allow multiple tab rows (TMP ext), ColorfulTab, or multiple session saving (Session Manager), savewithurl, etc., etc., and the many minimal themes (with TMP i can reduce the width of tabs, and with the dark Orange Fox theme get about 22 tabs indefinable across). Opera will not allow that, unless you can figure out how to edit the skin.

    Will all the customization, FF is a community of individuals with differences. But i get here searching for how to find the build number in FF 5. I do not see it in Help?>About

  58. I think we should be doing something like what Ubuntu does (not the “year.month” numbering), but where every so often they have a “LTS” (Long-Term Support) release that is supported much longer than other releases, all the way until the next long-term support release comes out. Then normal users could be on a normal track (the 6-week track), while corporations could just follow the LTS releases (so they don’t have to update every 6 weeks).

    Maybe you could even do version numbers with this – like “6.0” is the LTS release, then “6.1” after 6 weeks, “6.2” after 6 weeks, then eventually “7.0” will be the next LTS release. So normal users could go “6.0” > “6.1” > “6.2” etc… (with security updates and stuff, like “6.1.1” between “6.1” and “6.2”), while corporate users could go “6.0” > “7.0” etc… (with security updates and stuff, like “6.0.1” between “6.0” and “7.0”).

  59. I’ve been following this discussion for some time. But it can be wise to take a look at the osx versioning system. That has always been very consistent. Just the numbering not the wild cats.

  60. Asa Dotzler wrote:

    We have and we will break add-on API compatibility with every release, certainly binary add-on compat.

    I am worried about stability, security and add-on compatibility. Rushing new versions out the door every few weeks that break add-ons and then only receive security updates for a short time sounds crazy to me.

    Firefox has been my browser of choice (on Windows and Linux) for years and in the past I have been a strong advocate for it wherever possible. Now I am not so sure anymore …

    With the new release and versioning scheme you lose

    • Add-ons (that can’t catch up), which used to be the strength of Firefox
    • Time to test properly and thoroughly, i.e. you lose quality
    • The “most secure browser” reputation (due to short security update cycle)
    • Alignment with Open Source versioning standards and expectations
    • The special attention and cheer that used to come with major version releases
    • The distinction of major and minor upgrades

    Please review your release and versioning scheme and listen to input from the community.