Features/Jetpack/Add-on SDK as an Addon
Status
| Add-on SDK as an Addon | |
| Stage | Draft |
| Status | ` |
| Release target | ` |
| Health | OK |
| Status note | Investigating as part of post-1.0 planning |
{{#set:Feature name=Add-on SDK as an Addon
|Feature stage=Draft |Feature status=` |Feature version=` |Feature health=OK |Feature status note=Investigating as part of post-1.0 planning }}
Team
| 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 | ` |
{{#set:Feature product manager=David Mason
|Feature feature manager=` |Feature lead engineer=` |Feature security lead=` |Feature privacy lead=` |Feature localization lead=` |Feature accessibility lead=` |Feature qa lead=` |Feature ux lead=` |Feature product marketing lead=` |Feature operations lead=` |Feature 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
`
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
` {{#set:Feature open issues and risks=` |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
|Feature users and 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. |Feature dependencies=` |Feature requirements=` |Feature non-goals=` |Feature functional spec=` |Feature ux design=` |Feature implementation plan=` |Feature security review=` |Feature privacy review=` |Feature localization review=` |Feature accessibility review=` |Feature qa review=` |Feature operations review=` |Feature implementation notes=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. |Feature landing criteria=` }}
Feature details
| Priority | P3 |
| Rank | 999 |
| Theme / Goal | ` |
| Roadmap | Jetpack |
| Secondary roadmap | ` |
| Feature list | Jetpack |
| Project | ` |
| Engineering team | Jetpack |
{{#set:Feature priority=P3
|Feature rank=999 |Feature theme=` |Feature roadmap=Jetpack |Feature secondary roadmap=` |Feature list=Jetpack |Feature project=` |Feature engineering team=Jetpack }}
Team status notes
| status | notes | |
| Products | ` | ` |
| Engineering | ` | ` |
| Security | ` | ` |
| Privacy | ` | ` |
| Localization | ` | ` |
| Accessibility | ` | ` |
| Quality assurance | ` | ` |
| User experience | ` | ` |
| Product marketing | ` | ` |
| Operations | ` | ` |
{{#set:Feature products status=`
|Feature products notes=` |Feature engineering status=` |Feature engineering notes=` |Feature security status=` |Feature security health=` |Feature security notes=` |Feature privacy status=` |Feature privacy notes=` |Feature localization status=` |Feature localization notes=` |Feature accessibility status=` |Feature accessibility notes=` |Feature qa status=` |Feature qa notes=` |Feature ux status=` |Feature ux notes=` |Feature product marketing status=` |Feature product marketing notes=` |Feature operations status=` |Feature operations notes=` }}