Firefox/Go Faster/When To Use System Add-ons

From MozillaWiki
Jump to: navigation, search

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.