Skip to content

Instantly share code, notes, and snippets.

@Mossop
Forked from jeffgca/road_ahead_pt1.md
Last active December 14, 2015 01:49
Show Gist options
  • Save Mossop/5009632 to your computer and use it in GitHub Desktop.
Save Mossop/5009632 to your computer and use it in GitHub Desktop.

Add-on SDK: The Road Ahead

Until now the SDK has been released every 6 weeks, 3 weeks offset from Firefox releases. We are breaking this established release schedule and switching to release the SDK's apis in Firefox itself, starting with Firefox 21. I've been referring to this period of time as our 'awkward phase', where we disrupt the established schedule.

The Awkward Phase

By the time we reach the end of this 'awkward phase' we should have a much better story for packaging and Firefox compatibility: the SDK's apis will be maintained in our github repo, shipped with Firefox every 6 weeks, and add-ons that use these apis will no longer need to include a version of the SDK's apis in the add-on package.

In order to achieve these goals we have decided to make Add-on SDK 1.14 the last release of the SDK that will include the APIs. Firefox 21 will be the first version that includes the SDK APIs and they will match those shipped in SDK 1.14. After we ship SDK 1.14 on March 12 we will only release new SDK API features via Firefox, meaning the next time we introduce new SDK functionality will be with the release of Firefox 22.

SDK 1.14 also introduces some changes to how add-ons load SDK APIs. If you package your add-on using SDK 1.14, the resulting xpi will by default include all of the API dependencies needed to run the add-on as usual. If your xpi is run in Firefox 21 or greater, the SDK's loader will not load these packaged APIs, and will instead use the ones shipped with Firefox.

The Benefits

The shift to shipping in Firefox has clear benefits:

  1. developers will not need to re-pack their add-ons after SDK 1.14 in order to benefit from changes in the SDK, as the add-on will always use the APIs provided by newer versions of Firefox.

  2. the Jetpack team will decouple our releases of the cfx packaging tool from the 6 week train model. This tool should not need to change significantly so we should only need to update it on an as-needed basis.

  3. the Jetpack team will no longer need to maintain compatibility with a range of Firefox versions in a single code-base. This aspect alone will greatly reduce the complexity of our code in some areas, and allow us to more easily react to major platform changes.

  4. new features can be added to the SDK more quickly when they depend on changes to Firefox as the new features can ship in the same release as those changes rather than waiting for later.

  5. Firefox developers will be able to rely on the SDK apis when creating new Firefox features.

What's next?

Once Firefox 22 as been released, we will release a new cfx packaging tool; this version will not include the SDK's apis, and therefore will not include these apis in the add-ons it packages. Add-ons will be much smaller, and developers will no longer need to re-pack to the latest version in order to benefit from the latest bug fixes.

What I'm most excited are the cool projects the team will start working on for Firefox 22 and up - I'll publish a follow-up post on these plans tomorrow.

Add-on SDK: The Road Ahead

In my last post I talked about the process currently underway to shift SDK development to match the Firefox release schedule.

The next phase ( Firefox 23 & Up )

Shipping in Firefox does not mean that the SDK is 'done'; quite the opposite! The team still needs to maintain the SDK's apis with future versions of Firefox. As I mentioned in my previous post we do expect this work will be simplified because we will no longer need to support a range of Firefox versions with the same code-base.

What are we going to do with all this spare time? I'm glad you asked! There are three key initiatives that I mentioned in our Roadmap that are top priorities for Jetpack in 2013:

Simple, Powerful Firefox UI integration

Based on Stephen Shorlander's excellent mockups, we will be implementing a set of high-level, useful apis that allow developers to integrate custom UI into Firefox navigation bar in a reliable an efficient way. There will be no markup, no need to manually handle unload. These apis will be available to all add-on developers, not just those using the SDK.

Rapid Prototyping of Firefox features

One of the goals of the SDK has always been to help make Firefox feature development easier. We've come a long way towards helping this by embedding our powerful, module apis and CommonJS loader into Firefox, but we think we can go even farther by easing the pain for not only creating feature prototypes but also shipping the tried and tested code-base the prototype becomes in Firefox all using a modern, modular approach.

Awesome tools for Add-on Developers

A key goal for the team is to help improve the developer experience for add-on developers. We believe the best way to approach this problem is to create great native tools that leverage the work of the already fantastic Firefox Developer tools and provide add-on developers with the features they've been asking for, such as debugging, rapid prototyping and in-browser packaging.

A related goal for the team is to continue to support Add-on Builder as we move through this transition, and very shortly I will publish a roadmap for Add-on Builder that provides more detail about Builder's future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment