anuraag Posted August 26, 2011 Share Posted August 26, 2011 Feature overviewFirefox's switch to rapid releases has been stressful for add-on developers. Add-ons not hosted on AMO are especially pained, as they must update compatibility every 6 weeks without the benefit of automatic compatibility bumping.Since the release of Firefox 4 and 5, we've learned that there are many more non-hosted add-ons than we previously thought, mostly those installed by other software. Whether users make use of these add-ons or not, seeing an incompatible add-on prevents many users from upgrading to new versions of Firefox.More than 90% of add-ons are compatible from one version of Firefox to the next, and the ones that aren't usually have binary components that will need to be recompiled every release. If we change the default compatibility assumption, we can reduce the action needed to only the very small number of add-ons broken by the new release, rather than 100% of add-on developers.We would move to a model where Firefox assumes add-ons are compatible unless they have binary components, the author has explicitly said to strictly observe stated compatibility, or it is reported to AMO as incompatible through the Add-on Compatibility Reporter.It's possible and likely we will occasionally enable add-ons that don't actually work, but as we omit add-ons with binary components, this should not cause crashes and users will simply not have the functionality they expect, and will complain to the add-on author.This process would not remove the need for AMO's automatic compatibility bumping, as it's still preferred for authors to be aware of changes in Firefox and learn about upcoming deprecations and other changes.Functional specificationWhen Firefox needs to determine an add-on's compatibility, it should do the following:1. If the add-on is marked as compatible with the version, nothing needs to be done. The add-on remains enabled.2. If the add-on is not marked as compatible, Firefox will look at its install.rdf to see if the author has requested strict compatibility qualification. If they have, the add-on is incompatible and disabled.3. Next, Firefox will look for binary components in the add-on. If binary components are found, the add-on is incompatible and should be treated as such (disabled).4. If the add-on is not marked as compatible and does not contain binary components, Firefox should look at the metadata it received from AMO about the add-on. If the add-on is not reported as incompatible from AMO, it should be enabled as compatible.For AMO, this will involve returning information on compatibility reports received in response to metadata API requests, and support for returning information on non-hosted add-ons.Source Link to comment Share on other sites More sharing options...
Administrator DKT27 Posted August 26, 2011 Administrator Share Posted August 26, 2011 Yea read this few days ago. This will change lot of things. Mozilla really needs to push for jetpack though. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.