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.
> 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.
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:
(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:
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.
On Mon, Jun 28, 2010 at 9:36 AM, Dietrich Ayala <auton...@gmail.com> wrote: >> 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.
> 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:
> 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).
> 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.
