criteria for releasing a 1.0 beta

[Myk Melez]

Rocketeers!

I've been thinking lately about what would constitute an initial
beta-quality release on the road to the final release of SDK 1.0, and
I've come up with the following set of criteria:

1. Stable APIs

We shouldn't expect that we will make additional significant breaking
changes to the current APIs between a beta release and the final
release. That doesn't mean we can't make such changes, if circumstances
warrant, only that we don't anticipate doing so, because we're pretty
satisfied with the APIs as they are currently implemented.

2. E10S Compatibility

This is something of a subset of the first criterion about stable APIs,
since E10S compatibility requires significant breaking changes to the
current APIs, but it seemed important enough to call it out separately.

A beta should be E10S compatible, even if we haven't yet integrated E10S
support into the SDK, so that we don't have to make big changes to the
APIs for E10S compatibility in a subsequent release.

3. Most Core API Implementations

Most of the core APIs--i.e. the ones we think are most important to
provide and plan to ship as part of the SDK--should be implemented.
They don't all need to be there, but if a significant number are not yet
done, that makes it hard to justify calling a release a beta, since
potential addon developers will associate that label with a substantial
degree of completion.

4. Rename

We have been planning for several months to rename the product to a name
that better reflects the purpose of the SDK and its utility to addon
developers. We should do this before we go beta, since beta releases
will be marketed and distributed to a much broader audience of potential
addon developers, and it'll be harder to change the name after that.

5. High/Low Level API Distinction

We should make a distinction between the high-level APIs, which we have
developed to satisfy the common use cases of addon developers, and the
low-level APIs, which we have developed to help us implement the
high-level APIs, since clarity about the difference between those two
sets will go a long way towards helping developers navigate the
documentation, learn the API set, and use the toolkit.

There are also two criteria that I considered but ended up not including
in the list:

1. E10S Integration

E10S integration is an important requirement for the final release, but
I don't think it needs to land by the first beta, since it doesn't
change the behavior of the SDK for common use cases (provided E10S
compatibility itself has landed).

However, we do need to understand the form this integration will take
well enough to be comfortable that it won't require us to change E10S
compatible APIs significantly between the beta and the final release.
Otherwise, it will be hard to make the beta call.

2. enforcement of restrictions on the loading of modules not required by
an addon

This work, like E10S integration, is also an important requirement for
the final release, but I don't think it needs to land by the first beta
either, since it shouldn't significantly affect the behavior of the SDK
from the perspective of most addon developers, and adding it later
should not break common use cases.

Nevertheless, I would certainly welcome having E10S integration and the
module loading work done for the initial beta, and I know that Atul and
Brian are working hard to land those pieces as soon as possible (in fact
the latter is an 0.8 deliverable).

Does this seem like the right set of criteria for a beta release? Is
anything missing? Is anything there that shouldn't be?

-myk

[Irakli Gozalishvili]

Hi Myk,

I do think that fixing incompatibilities with commonjs is also something that needs to be addressed for the beta.


Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France

--
You received this message because you are subscribed to the Google Groups "mozilla-labs-jetpack" group.
To post to this group, send email to mozilla-la...@googlegroups.com.
To unsubscribe from this group, send email to mozilla-labs-jet...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mozilla-labs-jetpack?hl=en.

[Matěj Cepl]

Dne 27.8.2010 01:53, Irakli Gozalishvili napsal(a):

> I do think that fixing incompatibilities with commonjs is also something
> that needs to be addressed for the beta.

Bug numbers?

Matěj

[Dietrich Ayala]

Sounds great to me, thanks for writing this up!

[Irakli Gozalishvili]

I have submitted bugs for all each commonjs related issue:

https://bugzilla.mozilla.org/show_bug.cgi?id=591337
https://bugzilla.mozilla.org/show_bug.cgi?id=591338
https://bugzilla.mozilla.org/show_bug.cgi?id=591343

Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
Address: 29 Rue Saint-Georges, 75009 Paris, France

[Myk Melez]

On 08/27/2010 07:36 AM, Irakli Gozalishvili wrote:
> I have submitted bugs for all each commonjs related issue:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=591337
> https://bugzilla.mozilla.org/show_bug.cgi?id=591338
> https://bugzilla.mozilla.org/show_bug.cgi?id=591343

There isn't anything on this list that I would absolutely hold a beta
for, even if it meant sacrificing CommonJS compatibility for the final
version. But all of the suggested changes seem reasonable (modulo my
comments in bug 591343), and I would certainly accept them in the
current development cycle.

-myk