Jetpack/Ship SDK via AMO

Status

Team

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

`

Non-goals

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

`

Accessibility

`

Quality Assurance review

`

Operations review

`

Stage 4: Development

9. Implementation

Here's a prototype of what the add-on part might look like: https://builder.addons.mozilla.org/addon/1044630/latest/

Stage 5: Release

10. Landing criteria

`

Feature details

Team status notes