Features/Jetpack/Add-on SDK as an Addon

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


Add-on SDK as an Addon
Stage Draft
Status `
Release target `
Health OK
Status note Investigating as part of post-1.0 planning


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

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




Stage 2: Design

5. Functional specification


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

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

Priority P3
Rank 999
Theme / Goal `
Roadmap Jetpack
Secondary roadmap `
Feature list Jetpack
Project `
Engineering team Jetpack

Team status notes

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