One of the promises the SDK makes is to maintain compatibility for its "supported" or "high-level" APIs: meaning that code written against them will not need to change as new versions of Firefox are released.
This ties the SDK release cycle into the Firefox release cycle because the SDK must absorb any changes made to Firefox APIs. The SDK and Firefox both release every 6 weeks, and the releases are precisely staggered: so the SDK releases three weeks before Firefox. Each SDK release is tested against, and marked as compatible with, two versions of Firefox:
- the currently shipping Firefox version at the time the SDK is released
- the Beta Firefox version at the time the SDK is released - which, because SDK and Firefox releases are staggered, will become the currently shipping Firefox three week later
Add-ons built using a particular version of the SDK are marked as being compatible with those two versions of Firefox, meaning that in the
targetApplication field of the add-on's install.rdf:
minVersionis set to the currently shipping Firefox
maxVersionis set to the current Firefox Beta
See the SDK Release Schedule for the list of all SDK releases scheduled for 2012, along with the Firefox versions they are compatible with.
"Compatible By Default"
There are exceptions to the "compatible by default" rule: add-ons with binary XPCOM components, add-ons that have their compatibility set to less than Firefox 4, and add-ons that are repeatedly reported as incompatible, which are added to a compatibility override list.
From Firefox 10 onwards, Firefox treats add-ons as "compatible by default": that is, even if the Firefox installing the add-on is not inside the range defined in
targetApplication, Firefox will happily install it.
For example, although an add-on developed using version 1.6 of the SDK will be marked as compatible with only versions 11 and 12 of Firefox, users of Firefox 10 will still be able to install it.
But before version 10, Firefox assumed that add-ons were incompatible unless they were marked as compatible in the
targetApplication field: so an add-on developed using SDK 1.6 will not install on Firefox 9.
Changing minVersion and maxVersion Values
maxVersion values that are written into add-ons generated with the SDK are taken from the template file found at:
If you need to create add-ons which are compatible with a wider range of Firefox releases, you can edit this file to change the
Obviously, you should be careful to test the resulting add-on on the extra versions of Firefox you are including, because the version of the SDK you are using will not have been tested against them.
Suppose you create an add-on using version 1.6 of the SDK, and upload it to https://addons.mozilla.org/. It's compatible with versions 11 and 12 of Firefox, and indicates that in its
Now Firefox 13 is released. Suppose Firefox 13 does not change any of the APIs used by version 1.6 of the SDK. In this case the add-on will still work with Firefox 13.
But if Firefox 13 makes some incompatible changes, then the add-on will no longer work. In this case, we'll notify developers, who will need to:
- download and install a new version of the SDK
- rebuild their add-on using this version of the SDK
- update their XPI on https://addons.mozilla.org/ with the new version.
If you created the add-on using the Add-on Builder (please download your sources before the builder goes out of service in April 2014) rather than locally using the SDK, then it will be repacked automatically and you don't have to do this.
The reason add-ons need to be repacked when Firefox changes is that the SDK modules used by an add-on are packaged as part of the add-on, rather than part of Firefox. In the future we plan to start shipping SDK modules in Firefox, and repacking will not be needed any more.