Features/Jetpack/Add-on SDK as an Addon

Status

Team

Open issues/risks

`

Stage 1: Definition

1. Feature overview

The Add-on SDK is distributed as ZIP and tarball archives on ftp.mozilla.org. We should distribute it as an addon on addons.mozilla.org instead, because:

• AMO has built-in support for automated updates to newer versions
• AMO has built-in support for stable and beta distribution channels
• provided the SDK is able to package itself, it would make SDK developers eat their own dogfood
• it would enable the Builder to offload the time-consuming repacking process to the client
• it would open up the possibility of adding graphical addon development interfaces (like those in the original prototype, in Builder, and in Alexandre Poirot's port of the SDK's functionality to an addon) to Firefox itself
• it is a step towards merging the SDK and Builder into one product - this product could also be an open web app
• makes it easier for us to achieve "test without restart" which is already on the roadmap
• Removes the dependency of Python which is a stumbling block to Windows users
• Using the SDK to actually build itself (a complicated add-on) shows our confidence in the system to create a complex add-on

2. Users & use cases

The target audience is addon developers. The use case is an add-on developer using the Add-on SDK (either directly or via the Add-on Builder) to build an addon.

3. Dependencies

`

4. Requirements

`

Non-goals

`

Stage 2: Design

5. Functional specification

`

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

The current plan includes a good deal of investigative work. We need to make sure that the needs of the Builder (time consuming processes) cannot be solved in other ways that might reduce their priority on this work. We also need to investigate what it would take to achieve parity with what we currently ship. This work brings along the possibility of having to maintain two different code paths which we do not want to do.

It may be possible to take a small portion of the work, in the form of providing the functionality of cfx run and integrate that with the Builder. This also presents dual code path maintenance but is far less of a worry than trying to replicate more of the platform.

Stage 5: Release

10. Landing criteria

`

Feature details

Team status notes