Firefox/Go Faster/When To Use System Add-ons
From MozillaWiki
You should not use a System Add-on if
- It is a raw experiment of new functionality -> Use Test Pilot
- It is attempting to answer a summary from a segment of our users -> Use Shield / Recipes
- If it is not under rapid development/is unlikely to need out-of-cycle updates.
You might want to consider System Add-ons for
- A confirmed feature (i.e. has been through test pilot) that is still under rapid development
- Would like to be able to ship updates faster than the release train to get a better development/user feedback cycle.
- May need to update parts of it off-cycle, for example:
- e10s rollout needed to be updated off-cycle to push out to different amounts of release populations.
- Form autofill may need to be modified to account for changes in active websites.
- It is being pushed out to older users, for example:
- To try and get them to update
- To fix issues discovered that might block them updating.
- It is being pushed out to fix issues for release users, i.e. replacing the hotfix mechanism.
- You need to measure network conditions that only users see. However, anytime you're thinking of Making Network Requests From Firefox, there is specific guidance to follow.
Additional Considerations
- System add-ons are not just a way to skip the release trains
- System add-ons must be covered well with automated tests to give confidence when shipping
- Testing & release cycles will need to be considered and planned
- Developing within mozilla-central
- Any L10n requirements/changes will be constrained by the existing release train.
- You will need to ensure that any changes are complete at the end of the release train cycle, ready for uplift
- Hello had lots of feature based development, which wasn't always complete at the end of a cycle.
- Developing outside mozilla-central
- L10n is not constrained by the release train, but the methods used are likely to lead to a smaller proportion of locales having complete localisation
- You're not constrained by release cycles - you can choose when to release to mozilla-central (and then uplift/push to release if required).
- You'll need to consider reviews - Firefox changes typically need to be reviewed by a Firefox peer. Would this be suitable for snapshot based releases?
- There's more flexibility for the build system - you can use npm/libraries and ship only the output to the add-on in mozilla-central
- Of course, this may change for mozilla-central in the future.
- Hello also had its own "beta" add-on hosted on AMO, for testing out changes with a much smaller population before pushing to mozilla-central
- There was also a developer channel one for L10n people.
- There should be a way (via metrics, whatever) to assess whether a system add-on was successfully delivered. Both for individual users who report new issues, and to know whether we expect a certain percent of the population to never received it.
