Several times in the last couple of months I have found myself with a broken application because either:
1. An extension designed for the next version of FF/Tbird updated itself,
breaking compatibility with the version I was currently using;
2. FF/Tbird updated itself automatically, breaking one or more extensions
in the process.
It would be really helpful to have an option to control this behavior short of shutting off automatic updates for both add-ons and the application. Ideally the updater would not update an extension until the FF/Tbird version matched (e.g., don't update an extension to a version compatible with Tbird 7 until I'm using Tbird 7), and would not update FF/Tbird until all installed add-ons had an update compatible with the new version.
I have a similar problem.
Now that FF7 is out, but I'm still using FF4. Why? When FF5 came out, it prompted me to upgrade, but then not all my extensions supported FF5 yet, so I had to wait. A few months later, before I could upgrade to FF5, FF6 was out, and I lost the option to upgrade to FF5. Since not all my extensions supported FF6, I had to wait again. This cycle continues, and if I don't have all my extensions compatible with the newest Firefox at any time, I can never upgrade.
What I want is, providing two options when notifying an upgrade, both the newest version and the newest version that's compatible with all installed extensions. The old scheme of "upgrade, disable incompatible extensions, wait and pray" doesn't work now because it makes no sense to sacrifice functionality for a "slightly better" new version.
This was fixed by two features:
1. The add-on system changed so that add-ons defaulted to compatible; they did not require an arbitrary max/min version bump to remain compatible. https://wiki.mozilla.org/Features/Add-ons/Add-ons_Default_to_Compatible
2. We made an automated add-on scanner that checks for backwards incompatible API changes in new versions of Firefox/Thunderbird and alerts developers with a detailed breakdown of what they need to fix in their add-on. http://blog.mozilla.org/addons/2011/04/19/add-on-compatibility-rapid-releases/
Will this fix prevent an add-on from automatically updating to a version that only works in a version of FF/Bird I am not using? For example, if I'm still using FF 10 this prevents an add-in from upfating itself to a version that won't work on FF 10. That is the core problem that motivated filing this bug.
In theory it would prevent that because the add-on scanner will warn about which APIs have been deprecated. It's up to the developer though, really, to support the correct API for each version. In practice, APIs only rarely break and both the Firefox and Thunderbird team have been really good about putting in scanners for that breakage. We do the scanning early on in the Aurora cycle so that add-on devs have a good amount of time to address the breakage.
How does a developer release version 2.0 of Foo add-in, which is only compatible with FF 13 and up, in such a way that people using Foo 1.5 on FF 10 are not automatically updated? That's what is needed here.
This was always possible by specifying minVersion in the install.rdf of the add-on. With the new compatibility scanner, the developer now has a much better indicator of how/when to set their minVersion / maxVersion.