Jetpack/Ship SDK via AMO

From MozillaWiki
Jump to: navigation, search
Please use "Edit with form" above to edit this page.


Ship SDK via AMO
Stage Definition
Status In progress
Release target Jetpack Future
Health OK
Status note Investigating whether it's really possible.


Product manager Dave Mason
Directly Responsible Individual Wes Kocher
Lead engineer `
Security lead `
Privacy lead `
Localization lead `
Accessibility lead `
QA lead `
UX lead `
Product marketing lead `
Operations lead `
Additional members `

Open issues/risks

Is it technically possible? Would AMO reject it?

Stage 1: Definition

1. Feature overview

The Add-on SDK ships a new release every six weeks with new features and improvements, but every developer using the SDK needs to manually update to pick up the new release. Developers could check out the git repository and stay on the release branch, but that still requires manually updating, and it includes all of the repository's history, which addon devs don't need. If we had a way to leverage AMO's infrastructure to handle the updating process, developers could stay up to date easily to take advantage of improvements to the SDK.

This feature serves as a kind of halfway point between where the SDK is now and the eventual plan to ship the SDK itself as an add-on later this year (and shipping the SDK's libraries as part of Firefox itself after that).

2. Users & use cases

Addon developer Alex wants to write his extension with the SDK locally (eg, not using the Addon Builder website). He writes his extension with SDK version 1.5. A few weeks later, SDK 1.6 is released, containing necessary changes to the SDK's libraries for compatibility with upcoming releases of Firefox. Alex then needs to manually repack his extension with the new version of the SDK.

The way things are now, Alex needs to look for the release announcement for SDK 1.6 to find the download links to the 1.6 zip or tarball files, download that archive, extract it somewhere, activate 1.6's version of cfx, then repack the extension.

Instead, if the SDK could be updated via AMO, Firefox could prompt Alex to download the new version of the SDK, Firefox then downloads the zip or tarball and possibly even automatically unpack it somewhere on Alex's hard drive. All Alex then needs to do is activate cfx and repack his extension.

3. Dependencies


4. Requirements



The SDK does not ship itself as an addon. The dependency on python is not removed. The SDK doesn't ship as part of Firefox.

Stage 2: Design

5. Functional specification

A small helper add-on can be installed by the user into Firefox. This add-on then checks for updates to the SDK from somewhere, either as part of the add-on itself (so an update to the add-on is shipped every 6-weeks to stay in line with the SDK release cycle), or some list online (so the add-on does not need to be updated for each release, just some text file hosted on some Mozilla server). When an updated version is detected, the add-on shows some notification to the user, announcing the release and asking the user whether the new version should be downloaded. If the user chooses to download the new version, the add-on initiates the download of either the zip or tarball version of the release to somewhere on the user's hard drive. The add-on then extracts the SDK from the downloaded zip/tarball, and notifies the user that the new version of the SDK is ready to use from (whatever location the SDK was downloaded/extracted to). The add-on then records somewhere (simple-storage? some local text file?) that this version of the SDK has been downloaded, so that it won't prompt for it again.

Additionally, it would probably be good to allow the user to do something in the add-on to manually initiate a download of the latest (or some?) version of the SDK, in case the already-downloaded copy is deleted or moved.

6. User experience design


Stage 3: Planning

7. Implementation plan


8. Reviews

Security review


Privacy review


Localization review




Quality Assurance review


Operations review


Stage 4: Development

9. Implementation

Here's a prototype of what the add-on part might look like:

Stage 5: Release

10. Landing criteria


Feature details

Priority Unprioritized
Rank 999
Theme / Goal Experience
Roadmap Jetpack
Secondary roadmap Developer Tools
Feature list Jetpack
Project `
Engineering team Jetpack

Team status notes

  status notes
Products ` `
Engineering ` `
Security sec-review-unnecessary `
Privacy ` `
Localization ` `
Accessibility ` `
Quality assurance ` `
User experience ` `
Product marketing ` `
Operations ` `