Better Firefox Add-on Versioning

So I’ve been thinking about add-on versioning for Firefox going forward and I’m starting to think that maybe it’s being done backwards.

Right now we have to change either our add-on, an updateURL or AMO every time a new Firefox is released (every 6 weeks). Wouldn’t it make more sense to mark an add-on as compatible with every future version of Firefox (maxVersion of *)? Then you’d only need to do anything if you realize your add-on is NOT compatible, not change something for every version of Firefox…

Thoughts?

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published. Required fields are marked *

21 thoughts on “Better Firefox Add-on Versioning

  1. You right, but by making so people will think that their addons are compatible with any version and even if the addon is under active maintenance they might prefer not to update it to another version or it might be too late to fix and they’d simply uninstall the addon or the browser.

    Anyway, I think you can double the time required for each version bump to 12 weeks by testing the aurora branch at the same time you test the beta branch.

  2. I suspect the biggest reason addons become incompatible is because their authors stopped updating them. I don’t think it is very likely that these people will come back to mark their addon as incompatible. The result would be more addons falsely reporting themselves as compatible.

    • That was true before 4.0, but if you have updated your add-on for 4.0 and it does not contain binary components, it probably won’t break that quickly. These releases don’t have major changes in them to break add-ons (so far).

    • I realize that, but that’s still more work for you guys.

      And there are tons of add-ons that are not on AMO.

      At this point, I’m seriously considering setting all of my non-AMO add-ons to maxVersion of *.

      Otherwise my clients have to either referesh the add-ons or change their updateURLs every six weeks. That’s just a waste of time and energy.

  3. That seems like the right approach if you know that your add-on will always get tested with every new version of Firefox. But for every Adblock Plus or Firebug, AMO has quite a few extensions which don’t get nearly as much attention or maintenance; letting those extensions automatically run on new browsers, and potentially break, seems like the wrong approach. And even the extensions which *do* get maintained may need changes for new versions.

    Those problems occur because Firefox’s extension interfaces change over time, not just by introducing new features, but by changing or removing existing features. I think the right solution involves changing that, instead. As Firefox moves further in the direction of Chromeless, replacing XUL with HTML, I hope that much of the baseline extension functionality gets replaced with existing web standards, turning add-ons into trusted web apps that run in the browser context.

    Dialogs and other UI can mostly use HTML and JavaScript. Extensions could use unrestricted XHR for web access. Something similar to globalStorage would work well for most preferences. Careful use of DOM manipulation allows extending the browser UI at runtime. And with appropriate hooks provided to extensions, even operations like Adblock Plus’s URI filtering could work.

    Allowing web standards to subsume most of the extension API would do wonders for compatibility. The remaining compatibility issues would lie in only a couple of areas: the extensions to web standards for trusted usage, the bits of the browser UI that extensions rely on for their DOM manipulation, and the hooks provided for extensions like Adblock Plus. Just as security experts talk about “attack surface”, these changes would decrease the “compatibility surface”.

  4. Curious. . . what is the approach that Google Chrome uses, seeing that their Extensions/Add-Ons (thus far) seem to work with each new release of their browser?

    • Google chrome add-ons have no versioning. They’ve designed they’re add-on API so it works from version to version.

      • It’s also a much more restricted API, much closer to the Jetpack APIs, which is why they can maintain compat, instead of the “everything in the world” that Firefox extensions have available.

  5. That’s what I decided to do for BlueGriffon add-ons.

    Speaking of Firefox, now that Mozilla has moved to a faster release process, it’s a bit more painful for add-on authors. I read that AMO is going to automatically bump up the maxVersion field for _some_ add-ons. If that decision makes sense from Mozilla’s perspective, it does not make sense from a user’s perspective: anything – including a potentially horked add-on – is better than an add-on that suddenly goes away from the list of installed add-ons.
    With the faster process release, that scenario may happen MUCH more frequently than in the past, and from an average user’s point of view, that’s really not acceptable.

    So I agree 100% with you here.

    • Well I don’t. I have several tens of installed add-ons, and (in nightlies) I set the pref to override compatibility, but at least the addons manager still tells me which addons don’t advertise compatibility, so when (not if) a crash happens but not in Safe Mode I know where to look first.

      If in Firefox 0.9 time (when I started) every single addon had had a bogus “infinity” (or quasi-infinity) maxVersion, I wouldn’t know where to look for a possible culprit, I wouldn’t have had a “possibly dangerous” checkCompatibility=false to put me on guard, and I would be long gone from Firefox, because “it crashes” (actually, extensions misbehave, but how could have learnt that subtlety)?

  6. I believe that we could develop a smarter system based on three principles:

    1) Better API for API changes. Jetpack goes there with “features”. If I “require” sth and this sth has changed since I developed my extension, the risk that my way of using the API will not work anymore is higher. But this could be pushed further, maybe a scan to mark how I use the API, or maybe Jetpack API changes should be accompanied by automated tests (sth like py2to3) to warn about potentially obsolete use of the API?

    2) Mass-review. Having tens of thousands of beta-testers should allow us to get their help in picking which extensions doesn’t work anymore in the new beta. This is the model that I think Android AppStore uses – users report if the app works and based on the stats they are able to recognize which phones/android versions are supported by the given appversion.

    So a model may look like this: “Until we receive 10 positive opinions on this extension from its users in beta phase, we keep it marked as not ready for the next release.”

    3) A third state of matter (sth like “fuzzy” but milder) where the extension is known to work in Fx4 and Fx5 but unknown to work in Fx6. We don’t have enough negative feedback to call it “broken”, but we also did not receive enough positive feedback. In such case, a user should be warned but able to install it and Firefox should ask the user after a day or two if the extension works for him.

  7. With Songbird,(based on the Mozilla platform) I choose to use 2.0 as my maxVersion since there are no many API change between 2 version… problem is the Songbird addons website is not as cool as AMO, so many addons are not updated 🙁

  8. Where I work, we were burned by having a maxversion for a browser that didn’t exist yet. Mozilla nearly blacklisted us for it.

    On top of that, it doesn’t solve the problem for binary components. Binary components have to be recompiled for every major FF version.

    • Can you provide more detail on that? Why would Mozilla care what you put for maxVersion?

      I realize the binary component problem and clearly you wouldn’t do it for that.

      • Simple. If you were to write an extension with the following maxVersion settings:

        Firefox: 10.*
        Thunderbird: 10.*
        SeaMonkey: 3.*

        the AMO reviewers (or maybe the AMO automatic checks) would reject your extension without even looking at the rest: such high maxVersion values are NOT YET PERMITTED, period.

        I understood your post as meaning you want to *abolish* any “permitted range” of maxVersion values, and I have strong misgivings about that, but IIUC Alex was talking about something that happened in the past, and yes, with the present state of affairs, only certain maxVersion values are permitted.

        • You’re right. The automatic checks reject it and that’s fine.

          But Alex seems to indicate that he did a high maxVersion with a non AMO add-on and it almost got blacklisted. That seems wrong.

          • I don’t recall Alex’s case specifically, but when an add-on claims compatibility with future versions of Firefox and it turns out the add-on causes crashes because it’s not actually compatible, our only option is to block that version of the add-on in the future versions of Firefox.

  9. I have used Firefox since v.2. and i am a companyuser/homeuser. Every major upgrade to a new version means that addons stop working. Sometimes the addons i really need. Now when version 4 was released it was the same again, several became deactivated due to incompability as Firefox put it. From version 4 to 5 even more stopped working. Every time i have to change a line in each addons install.rdf-file – max version number. After done that they work without any problems at all. What i don’t understand is why Mozilla don’t remove the compabilitycheck when it is only this line that need to be changed ? I know some addons might not work fully after that change, but they sure are accepted and work helpful enough. Now i have changed from Firefox to Palemoon, coz it takes a lot less systemresources to run and it is clearly a lot faster to renedering java and flash. It is tweaked in a great way i have to say. Why can’t Mozilla do this to ? Firefox eats too much systemresources. 🙁