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.
How will this process work?
There are three key parts:
- 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.
- 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.
- 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.