Jetpack/Roadmap-2011: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
__NOTOC__
= '''Jetpack High-Level Product Roadmap''' =
= '''Jetpack High-Level Product Roadmap''' =


Line 164: Line 162:
= '''SDK 1.0 Goals''' =
= '''SDK 1.0 Goals''' =


* A carefully selected set of APIs that satisfies the common use cases of addons;
* A sublime user experience vastly superior to the traditional addon development model;
* A robust security infrastructure that restricts access to unnecessary privileges;
* The execution of addons in separate processes for performance and responsiveness;
* A coherent plan and process for maintaining API compatibility across multiple Firefox releases.
And how do we know when we satisfy the common use cases and are
providing a sublime user experience? One good metric is SDK usage
relative to usage of the traditional model, as evidenced by the ratio of
SDK-based vs. traditional addons being submitted to AMO. When a majority
of new addons are SDK-based (and perhaps even sooner), we'll have
certainly arrived.
NOTE: Some of these are already achieved by the move to the SDK approach, and some made obsolete/irrelevant. These goals need updating.
NOTE: Some of these are already achieved by the move to the SDK approach, and some made obsolete/irrelevant. These goals need updating.


Previous 1.0 set, needs integration into above:
* '''A seamless install process''': It defeats the purpose of Jetpack to first require users to install Jetpack, then install a particular Jetpack, before using its features. Instead, we need a solution which allows a seamless install process.
* '''A seamless install process''': It defeats the purpose of Jetpack to first require users to install Jetpack, then install a particular Jetpack, before using its features. Instead, we need a solution which allows a seamless install process.
* '''Seamless debugging''': No pointless error messages, and all relevant warnings, line numbers, and tracebacks, are displayed.
* '''Seamless debugging''': No pointless error messages, and all relevant warnings, line numbers, and tracebacks, are displayed.

Revision as of 18:11, 30 June 2010

Jetpack High-Level Product Roadmap

Jetpack development comprises numerous releases of multiple products that achieve four major milestones, which this chart summarizes.

Milestone One Milestone Two Milestone Three Milestone Four Milestone Five
Jetpack Prototype Jetpack SDK 0.1 Jetpack SDK 0.2 - 1.0b Jetpack SDK 1.0 Jetpack SDK Future
ETA DONE, 2009 Q4 DONE, 2010 Q1 2010 Q2 - Q3 2010 Q4 2011 Q1
Firefox Extension Manager no-restart API, transparent content iframes, addon bar Support for Jetpack-native packages, Jetpack library in core?
Platform Chrome object wrappers, OOP Jetpack ECMAScript 5?
AMO Stats on Jetpack-built extensions Support for Jetpack-native packages
Security Reduced-privilege security model ES5-based API hardening?
L10N web service Jetpack-native APIs/tools
API Prototypes and proposals of various APIs Implementation of robust library satisfying common add-on use-cases Stable core library, community library collections
Dev Tools Bespin-based editor in extension Command line FlightDeck web-based IDE Firefox HUD console integration
Distribution Individual JS files XPIs w/embedded Jetpack runtime Jetpack-native packages (JPIs?)
Documentation bundled with SDK bundled with Flightdeck MDC


SDK Release Roadmap

Included from Labs/Jetpack/SDK:



SDK 1.0 Goals

  • A carefully selected set of APIs that satisfies the common use cases of addons;
  • A sublime user experience vastly superior to the traditional addon development model;
  • A robust security infrastructure that restricts access to unnecessary privileges;
  • The execution of addons in separate processes for performance and responsiveness;
  • A coherent plan and process for maintaining API compatibility across multiple Firefox releases.

And how do we know when we satisfy the common use cases and are providing a sublime user experience? One good metric is SDK usage relative to usage of the traditional model, as evidenced by the ratio of SDK-based vs. traditional addons being submitted to AMO. When a majority of new addons are SDK-based (and perhaps even sooner), we'll have certainly arrived. NOTE: Some of these are already achieved by the move to the SDK approach, and some made obsolete/irrelevant. These goals need updating.

Previous 1.0 set, needs integration into above:

  • A seamless install process: It defeats the purpose of Jetpack to first require users to install Jetpack, then install a particular Jetpack, before using its features. Instead, we need a solution which allows a seamless install process.
  • Seamless debugging: No pointless error messages, and all relevant warnings, line numbers, and tracebacks, are displayed.
  • Enabling API: An API deep enough to support a large range of add-ons. It is a non-goal in 1.0 to support everything, instead it is to support 80% of the long-tail of add-ons. The exact feature set of the API will be determined by a set of target add-ons (TBD) and feedback from Jetpack authors.
    • Frozen API: Although the API may be versioned, we the API will be backwards compatible from 1.0 on.
  • Beautiful by default: A set of OS-specific icons, as well as a beautiful look for Jetpacks.
  • Security-sensitive Import mechanism: The strength of any API is measured in how easily 3rd parties can extend it. The 1.0 release will have a strong import mechanism, replete with security provisions.
  • Security: A functioning security system that mixes code with social protections.
    • An AMO-like service with social code-review
  • Localization story
  • Works on Fennec