Canmove, confirm, emeritus
1,043
edits
Changes
Created page with "{{FeatureStatus |Feature name=Add-ons Default to Compatible |Feature stage=Draft |Feature version=Firefox 8 |Feature health=OK |Feature status note=Writing spec. }} {{FeatureTeam..."
{{FeatureStatus
|Feature name=Add-ons Default to Compatible
|Feature stage=Draft
|Feature version=Firefox 8
|Feature health=OK
|Feature status note=Writing spec.
}}
{{FeatureTeam
|Feature product manager=Justin Scott
|Feature feature manager=Justin Scott
|Feature lead engineer=Dave Townsend, Wil Clouser
|Feature qa lead=Henrik Skupin
|Feature ux lead=Jennifer Boriss
|Feature product marketing lead=Dan Horner
}}
{{FeaturePageBody
|Feature overview=Firefox'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.
|Feature functional spec=When 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.
}}
{{FeatureInfo
|Feature priority=Unprioritized
|Feature roadmap=Add-ons
|Feature secondary roadmap=Firefox Desktop
|Feature list=Desktop
|Feature engineering team=Desktop front-end
}}
{{FeatureTeamStatus}}
|Feature name=Add-ons Default to Compatible
|Feature stage=Draft
|Feature version=Firefox 8
|Feature health=OK
|Feature status note=Writing spec.
}}
{{FeatureTeam
|Feature product manager=Justin Scott
|Feature feature manager=Justin Scott
|Feature lead engineer=Dave Townsend, Wil Clouser
|Feature qa lead=Henrik Skupin
|Feature ux lead=Jennifer Boriss
|Feature product marketing lead=Dan Horner
}}
{{FeaturePageBody
|Feature overview=Firefox'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.
|Feature functional spec=When 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.
}}
{{FeatureInfo
|Feature priority=Unprioritized
|Feature roadmap=Add-ons
|Feature secondary roadmap=Firefox Desktop
|Feature list=Desktop
|Feature engineering team=Desktop front-end
}}
{{FeatureTeamStatus}}
