targeting an SDK 1.0 release by end of year

0 views
Skip to first unread message

Myk Melez

unread,
Jun 27, 2010, 4:51:00 AM6/27/10
to mozilla-la...@googlegroups.com
Rocketeers!

As I mentioned at last Tuesday's weekly meeting, I think we should aim to reach an SDK 1.0 production release by the end of this calendar year. The primary reason is that we've been working on the SDK for almost a year now (and the Jetpack project as a whole for over a year), and we've done a bunch of great work that we should get into the hands of developers who could benefit from it.

Of course developers can use the SDK today, but each successive stage of the development process (alpha, beta, production) attracts a larger set of developers, and we should aim to get our work out to the broadest possible audience of developers, including those who only use stable production releases.

A secondary reason to release by the end of the year is that doing so supports the upcoming Firefox 4 release, even if the SDK release won't be specifically aligned with Firefox 4 (otherwise we'd want to do it months in advance of Firefox's release), since the closer we are to a production release when addon developers start targeting Firefox 4 (updating their addons and/or creating new ones), the more developers we can help.

There's still plenty of work to do, of course, including additional APIs, security functionality, and E10S support. But releasing at the end of the year gives us the time to get that work done, provided we scope it carefully and focus on it intently.

What comprises a 1.0 release? Here's an initial take:
  • 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.

Does this seem like a reasonable plan?

-myk

Dietrich Ayala

unread,
Jun 28, 2010, 12:36:43 PM6/28/10
to mozilla-la...@googlegroups.com
> 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.

Sounds great Myk. How should we track this set of criteria? Bugs?
Should we make reviewing this set part of our monthly release process?

It also might help to sign individuals up to own/drive some of these pieces.

Dietrich Ayala

unread,
Jun 30, 2010, 4:31:08 PM6/30/10
to mozilla-la...@googlegroups.com
I updated the wiki with these goals, the upcoming planned releases,
and fixed the roadmap to better reflect where we're at:

https://wiki.mozilla.org/Labs/Jetpack/Roadmap

I also updated each release page with a small status snippet that can
be transcluded, in the form of "{status: date}", where status is
either "Released" or "Planned". The SDK page now lists all releases
with their status:

https://wiki.mozilla.org/Labs/Jetpack/SDK

(That combined status list for all releases is also transcludable, and
as you can see on the roadmap page, and the Firefox project page for
Jetpack)

Finally, I've started a page for the list of platform capabilities and
high-level APIs required to meet our 1.0 goals. So far I just have the
list of items we don't yet have, as talked about in the meeting:

https://wiki.mozilla.org/Labs/Jetpack/SDK/APIs

This isn't a permanent home (that would be the docs), but a place for
us to get a high-level overview of what the SDK has, and what it's
missing, as we drive to 1.0.

Dietrich Ayala

unread,
Jun 30, 2010, 5:30:03 PM6/30/10
to mozilla-la...@googlegroups.com
> Finally, I've started a page for the list of platform capabilities and
> high-level APIs required to meet our 1.0 goals. So far I just have the
> list of items we don't yet have, as talked about in the meeting:
>
> https://wiki.mozilla.org/Labs/Jetpack/SDK/APIs
>
> This isn't a permanent home (that would be the docs), but a place for
> us to get a high-level overview of what the SDK has, and what it's
> missing, as we drive to 1.0.

I updated this page with a section for platform-level capabilities,
and a section for high-level APIs we currently have.

Please take a look, and add/update/remove as necessary (or reply here
or on the talk page if you don't want to update the wiki).

Myk Melez

unread,
Jul 3, 2010, 10:25:32 AM7/3/10
to mozilla-la...@googlegroups.com
On 06/28/2010 05:36 PM, Dietrich Ayala wrote:
> Sounds great Myk. How should we track this set of criteria? Bugs?
> Should we make reviewing this set part of our monthly release process?
Yes, let's review these at least monthly in our weekly meetings. And
let's track them via wiki pages, which seem to work a bit better than
bugs for non-specific criteria.

> It also might help to sign individuals up to own/drive some of these pieces.

Definitely! Let's talk about that at the next review.


On 06/30/2010 09:31 PM, Dietrich Ayala wrote:
> I updated the wiki with these goals, the upcoming planned releases,
> and fixed the roadmap to better reflect where we're at:

...


> I also updated each release page with a small status snippet

...


> Finally, I've started a page for the list of platform capabilities and
> high-level APIs required to meet our 1.0 goals.

Thanks Dietrich, this is all awesome!

-myk

Reply all
Reply to author
Forward
0 new messages