Mozilla Add-ons Community Blog
Categories: compatibility developers

Add-on Compatibility & Rapid Releases

28 responses

Firefox development has recently moved to a rapid release cycle to bring new features and security, stability, and other bug fixes to hundreds of millions of users much faster than we have previously. In order to support this exciting new release schedule, a lot has to change, and one of the biggest areas impacted is add-on compatibility.

With past Firefox releases, add-ons were not marked as compatible with a new version until the developer manually tested and updated their add-on to support it. This process took months to get compatibility to an acceptable level and only worked because of the infrequency of Firefox releases. Our proposed plan for compatibility going forward assumes add-ons are compatible unless we find evidence that they aren’t.

Under the new proposal, add-ons hosted on AMO that are compatible with the previous major release will be automatically marked as compatible with a version just before it branches to Aurora unless we detect that the add-on is broken. Users of Aurora, Beta, and final releases should automatically have compatibility for the vast majority of their add-ons. Nightly users will still need to disable compatibility checking as they currently do, preferably by installing the Add-on Compatibility Reporter.

Compatibility flow

How will this process work?

There are three key parts:

  1. Firefox and platform developers should take add-on compatibility into account with any changes they make. Add-on compatibility will be included in the criteria for changes being promoted to Aurora and Beta channels. It’s especially important to minimize breaking changes for Firefox 5 & 6 when the Add-on SDK is not yet stable. Once released this summer, the Add-on SDK will be an excellent alternative to dealing with compatibility.
  2. Before any compatibility-breaking changes land, Firefox developers should follow a standardized compatibility notification process with a description of the change, the reasons for the change, and patterns we can look for in add-ons to identify those affected. This will be used to update documentation, make blog posts, and add the patterns to the AMO compatibility scanner.
  3. The day before we branch for Aurora, AMO’s compatibility scanner will be run on the latest versions of all add-ons compatible with the most recent release. Any add-ons flagged as potentially incompatible or that use binary components will not have their compatibility bumped and the authors will receive an email with the identified problems. After testing and fixing any problems, the author can then manually set compatibility and rejoin the automatic process for future releases. Add-ons that have not been flagged will have their compatibility bumped to the new version.

Add-ons that aren’t hosted on AMO can use their own updateURL mechanism to bump compatibility without issuing an actual update, just as AMO does. They’ll also be able to use our standalone validator to run compatibility tests without being hosted on AMO.

We realize that some changes, especially those involving the user interface, will be difficult to automatically detect. In the next phase, we’ll work on integration with compatibility reports from Nightly users of the Compatibility Reporter to detect when an add-on has suddenly broken.

But Aurora 5 is already out!

We’re still working on the tools to be able to scan for compatibility, notify authors, and automatically bump add-ons, so this process isn’t in place for Aurora 5. We expect to be able to automatically bump 4.0.* compatible add-ons to 5.* during the Beta period. Note that the flow shown in the image above indicates that each channel has 6 weeks; however, Firefox 5 is on an even faster cycle and the releases do not yet line up as shown.

We’re looking for feedback on this proposal and invite you to participate in discussions in its newsgroup thread.

28 comments on “Add-on Compatibility & Rapid Releases”

  1. Justin Scott (fligtar) wrote on

    Just a note to anyone offering feedback here: I’ll be away for the rest of this week, returning Tuesday April 26. I’ll be able to reply to your feedback then. Thanks!

  2. Kohei Yoshino wrote on

    Japanese translation of this article:
    https://dev.mozilla.jp/2011/04/add-on-compatibility-rapid-releases/

  3. Jon Bresler wrote on

    I have Aurora, and of my 14 add-ons, only 1, F1 my Mozilla Labs, is enabled? Have problems really been found with that many add-ons?

  4. Jon Bresler wrote on

    Are you going to fix the lack of add-on’s issue or should I uninstall Aurora? Tired of not having my add-ons, but would be willing to test if they were there.

    1. Stephanie Daugherty wrote on

      As far as I know, the version bump happened later in the process the first time than it will going forward. You can always easily disable compatibility checking using Addon Compatibility Reporter or Nightly Tester Tools, or manually via about:config and try to run addons before their compatibility has been updated — most will work just fine, and it’s helpful to make developers aware early of the ones that don’t.

  5. Wladimir Palant wrote on

    Maybe this upgrading of compatibility info should only consider the current versions of add-ons? I received three mails, for three outdated versions of my add-ons. All the current versions are already marked as compatible with 6.0a2.

    1. Justin Scott (fligtar) wrote on

      Yeah, that’s bug 658739. We only intended to bump the latest reviewed version plus any beta or unreviewed versions created since the last reviewed version.

  6. Marc wrote on

    I am very concerned about Firefox 5.

    I have a add-on with binary XPCOM component compiled to 6 or 7 platforms and unhappily, it seems not work anymore with Firefox 5 ? Why ? So, I read the doc and see this,

    [[ Note: Firefox 5 requires that binary components be recompiled, as do all major releases of Firefox. See Binary Interfaces for details.]]

    Really you are joking ? This means for me, impossible to maintain the extension. I have a wife, children, a job and other things to do that to compile betas of firefox each 3 months on 6 platforms…

    Further….

    [[Traditionally, Mozilla has maintained a set of XPCOM interfaces and functions with the @status FROZEN marking. Using these interfaces, and using dynamic calls to QueryInterface, it has been possible to write binary XPCOM components which were compatible with multiple versions of Firefox. Beginning with Mozilla 2 (Firefox 4), this will no longer be supported: all @status markings have been removed, and extensions that use binary components will need to recompile for each major version they wish to support.

    JS-ctypes is the recommended way for extensions to call into OS or third-party native code.
    If necessary, it is possible for an extension to support multiple versions by shipping multiple shared libraries (DLLs) in the same extension package, and selecting the correct version using versioning flags in its chrome.manifest file.
    JSAPI, NSPR, NSS, and other libraries which are currently shipped as separate shared libraries may be integrated into libxul, and extension authors should avoid linking against them.
    ]]

  7. cfl wrote on

    Any way to opt out of these automated version bumps? Or at least mark in amo that one of my add-ons is *known* to be incompatible with e.g. Firefox 6? Otherwise, I suspect this is going to get annoying.

    re: “We only intended to bump the latest reviewed version plus any beta or unreviewed versions created since the last reviewed version.”
    If there is a beta version that’s compatible and the reviewed version is not, there is a real possibility that the beta is fixing an incompatibility with the release version. Just a thought.

  8. Eddie Weber wrote on

    I’m getting reports from users who say that New Tab King is not compliant with Firefox 5.0.
    This is weird since the extension is marked to be ok with: Firefox 3.0 – 6.0a1
    https://addons.mozilla.org/en-us/firefox/addon/new-tab-king/

    Any advice?

  9. Gilad wrote on

    I’ve got a notification that my add-ons are compatible with FF 5 (and also for FF 6). The add-ons version was updated correctly to reflect the compatibility. However, on Firefox itself all the addons are disabled with the incompatibility message.

  10. Michael Uplawski wrote on

    The comment by Marc, above, reveals some serious issues, as his extension is one of impact and importance. The surprise that he expresses in his message should have shocked those who took the decision for the “rapid release cycle” as it shocks myself.

    You win some, you lose some. Right?

  11. Rob H wrote on

    I would agree with Marc. We have a USB based device that our customers expect to be able to update by using our website and either an ‘IE with ActiveX’ solution or a ‘Firefox/XPCOM’ combo. The Firefox option is the only one we have for Mac. We got the Firefox 4.0 thing squared away and now all our customers are being automatically updated to Firefox 5.0 and … it doesn’t work???? This is for hundreds if not thousands of people. Great.

    It would be really unfeasible for our small shop to re-build/test our XPCOM package for each major Firefox release, so I’m a little shocked that there is a general expectation for add-on developers to re-build for every major Firefox release? I am interested to see how this plays out for others.

    For us, apparently the thing to do would be to use the ctypes option. So, we have a solution to try anyway… but it sure would have nice to know this back when the binary-component instructions for FF 4.0 came out.

  12. Yvonne Taylor wrote on

    Well I personally think all this should have been worked out BEFORE releasing the new Firefox. I really do not want to have to deal with each and every add on to make it work with workarounds and there are two addons i think may be more important than downloading a new version, for me any way. It says it will disable them and there is no update for them available yet- AVG Safe Search and Advertising Cookie Opt out. So when these are working with the new Firefox version I will then download it thank you very much.

  13. Joe wrote on

    I think the rapid cycle is just plain wrong. Currenly I am stick with 4.0.1, because two of my extensions I cannot live without are marked as not compatible (lastest versions) – should I hack the compatiblity check to use the latest version, or just use an outdated Firefox with possible security issues.
    In the past I had the option to wait until the extension is updated – there were security updates for older Firefox releases, but now I am just forced to either stop using Firefox or use a possibly vulnerable one.

    I am really unhappy about this and considering downgrade to Firefox 3.6.x which still is updated for security issues.

  14. John wrote on

    My university is on a yearly update cycle (at best) and I don’t want to think about how foobar this new update process is going to impact my courses. I use certain add-ons in the course, most importantly the HTML Validator which has compiled components which have to be rebuilt for each version upgrade! I’m going to have to try to get IT to stop firefox from updating itself so a version update doesn’t break the computer labs for months while the add-on must be updated and the semester is almost over by the time we can use the tools we need. This is going to be even more trouble as IT loves security updates and it appears you no longer do those but instead require whole version upgrades?

    Furthermore, I never liked the #.#.# crazy versions used in software; this is a community app so you’d think the idiot marketing people wouldn’t be insisting on 4.0 and would allow a logical 4.1 instead of 4.0.1 especially when you plan to cycle versions quickly. I don’t mind rapid releases… if they don’t conflict and confuse people. Can’t we maintain binary compatibility on a semester basis?? I don’t care much about how goofy you number things but small IT depts are going to suffer– as well as my students who are going to have MORE troubles at home as a result of this mess. I hope this mess gets fixed by the fall!

  15. Joe T. wrote on

    “Users of Aurora, Beta, and final releases should automatically have compatibility for the vast majority of their add-ons. Nightly users will still need to disable compatibility checking as they currently do, preferably by installing the Add-on Compatibility Reporter.”

    In direct contradiction to this statement, when i installed FF6beta, about 1/3 of my addons were automatically disabled. A couple of them actually weren’t compatible (for reasons i don’t understand, since the release notes for v6 don’t seem to indicate any major changes to extensibility). For the remaining ones that ARE compatible, i had to install the ACR to re-enable them…in the beta release…that the above statement says shouldn’t be necessary.

    In addition to the above contradiction, after installing ACR, i can’t seem to report the compatible addons as such. It’s as if the ACR itself isn’t working properly. How ironic.

    If this kind of frustration continues, i’ll probably be forced to abandon Mozilla. At least this time i’ll have a better option than IE. i’m a web dev, and Firebug is what i live on, but i’ve grown increasingly frustrated that it’s not part of the browser core (as dev tools are now with everyone EXCEPT Mozilla), and this new release cycle where Firebug is chasing new Firefox versions is really irritating.

    Change course Mozilla. i think users will be able to forgive the nightmare that was the 4.x release cycle, but this new path is a wrong decision for all the wrong reasons.

    1. Justin Scott (fligtar) wrote on

      Add-ons aren’t immediately compatible with Aurora because changes can land up to the last minute and we need time to write and test our compatibility scanners. They should be compatible within 2 weeks of a new Aurora version. In the meantime you can use the Add-on Compatibility Reporter. There is a bug in the current version that the report buttons only show up the first time you use it in a session. It will be fixed later today.

  16. Erik L Eidt wrote on

    As an end user, I’d like to validate that extensions I depend on are at least marked to work before an upgrade instead of only finding out after the upgrade… I’m looking at upgrading to ff 6 today, but am unsure. I don’t see how to validate whether my extensions will work — before the upgrade. How can I check them, in advance and en masse?

    Thanks,
    Erik

    1. Erik L Eidt wrote on

      Ok, it’s not obvious but if you go one step further toward upgrading, it will tell you what I was looking for.

  17. James wrote on

    Right — that is so confusing. It’s only after you apparently agree to the upgrade that you’re told which add-ons will stop working, and given the option to backtrack. This is backwards: we should be given this information first, to help with the decision about when to upgrade.

  18. Marc wrote on

    Thanks. I’ve officially started turning off the automatic update feature on all of the Firefox installations I manage because of this “rapid release” nonsense.

    If you really want to continue forward with this rapid-release thing, then add the option to only offer the upgrade if my extensions are compatible. Offering Firefox 6.0 to me every day without a “don’t notify me again” option was not very appreciated. Allowing me to install an upgrade only to tell me later, “sorry, we’re going to turn off your extensions” is not appreciated either.

    1. Pat Hallihan wrote on

      I agree. I would simply like the addon checker to happen pre installation so that it says if you continue with the upgrade these addons will be disabled. I can then wait and run the installer every so often and when the addons list as being compatible I can proceed with the update. For now I just don’t update for a week or so and it has worked alright for me, but it is quite annoying. Especially when an incremental comes out and I have to wait another week (this rapid release has me to paranoid to assume the incrementals have the same addon capability as the main ones). Having the addon compatibility happening before the install would make the rapid release and easier pill to swallow for the average user.

  19. goob wrote on

    This is the beginning of the end for FF, I fear. Chrome, here I (reluctantly) come…

  20. Rainer wrote on

    Please explicitly state whether the process decribed in this blog entry has been deployed,
    or when it is going to be.

    This blog entry gives the impression that from Firefox 6.0 at the latest, add-ons would automatically be marked as compatible unless proven to not be.
    However, on every release for both Firefox (6 and 7) and Seamonkey (2.3 and 2.4) I still have to explicitly suppress the compatibility checks to enable most add-ons.
    And they do work, as far as I can see.
    In my impression, only those add-ons work out of the box which have explicitly been marked as compatible by the developer.

    How strict is the compatibility check intended to be?
    When is an add-on “incompatible”? As soon as a single issue creeps up?
    Or only when the main functionality no longer works? I’d suggest the latter.

    1. Justin Scott (fligtar) wrote on

      The process has been in effect since Firefox’s launch several months ago, but it only works for add-ons obtained from addons.mozilla.org. If you have add-ons that you downloaded elsewhere, they may be incompatible. For more information, see http://blog.fligtar.com/2011/09/26/add-on-compatibility-progress-plans/

  21. Sasha van den Heetkamp wrote on

    The bumping-up methodology is great. It would be really excellent if the developer can scale up the compatibility for future releases inside the add-on itself, preventing issues forthcoming due to rapid releases.

  22. Rainer wrote on

    Justin, thanks for your reply.
    As far as I remember, all my add-ons are from addons.mozilla.org.

    Looks like l have to check why the individual add-ons are not marked as compatible.
    JavaConsole 7.0, RefControl and Perspectives, mainly.

    Does the process mark add-ons as being compatible with Seamonkey as well (or does this even make a difference)?