This document describes the process (a.k.a. "flow") by which the Add-on SDK is developed. For information about the process by which versions of the SDK are released, see Release Process.

Release Schedule

We ship a stable SDK release on a regular schedule every six weeks, at least as often as Firefox, to ensure we can accommodate incompatible changes to Firefox and remain compatible with it. Each release undergoes six weeks of development and six of stabilization, so a complete development cycle lasts twelve weeks, and cycles overlap by six weeks (while one release is stabilized, the next one is developed).

We release each SDK version three weeks before each new version of Firefox is released. This allows enough time for compatibility fixes to land on the SDK's stabilization branch after Firefox stops accepting incompatible changes (at the time it merges from aurora to beta?) while still giving AMO and addon developers enough time to update addons to use the new version of the SDK.

Each SDK release is compatible with the current and upcoming versions of Firefox. For example, SDK 1.2, which ships after Firefox 7 but before Firefox 8, is compatible with those two versions of Firefox.

Note: SDK 1.0's schedule did not follow this process. SDK 1.1's schedule was slightly irregular. SDK 1.2's stabilization cycle and SDK 1.3's development cycle were only five weeks long in order to change the offset between SDK and Firefox releases from two weeks to three weeks.

Development Branches

We maintain three branches: a development branch (dev), a stabilization branch (stab), and a release branch (rel). Each release spends six weeks on each branch, starting with six weeks of feature development on dev, after which it is merged to stab; continuing with six weeks of feature stabilization on stab, after which it is merged to rel; and concluding with six weeks of statis on rel.

Code changes are subject to conventional Mozilla quality controls (reviews, unit tests, etc.). We may introduce additional quality controls in the future (f.e. a requirement that new features and enhancements initially be marked experimental and be isolated from non-experimental use of the product). We achieve quality goals for stab and rel by fixing bugs and cutting features.

Rel maintains compatibility with Firefox's release and beta branches. Stab maintains compatibility with Firefox's beta and aurora branches. Dev maintains compatibility with aurora and central branches.

Distribution Channels

We distribute code to three distribution channels: an unstable development channel, a semi-stable test channel, and a stable release channel.

The development channel is the code repository itself; we encourage interested parties to clone it or download source tarballs from it. The test channel is the project discussion group; we spin beta, release candidate (candidate), and final release (final) builds once per week and announce them in the group. The release channel is the Add-ons Blog (and other communications, as appropriate); we announce final release builds in the blog.

We don't provide automated updates to newer releases, but we may do so in the future.

Version Identifiers

Releases have version identifiers of the format (major).(minor)[.fix], and we communicate them to users. We typically increment the minor number for each release. We add a "fix" number and ship a release with it only under exceptional circumstances (f.e. an urgent security issue).

We update the version on dev at the beginning of each cycle to be (major).(minor)a0, where (major).(minor) represents the identifier with which we intend to ship the code under development, f.e. 1.3a0 when dev represents the code we intend to ship as SDK 1.3, which indicates:

via (major).(minor), the version under development;
via "a", that the code is at an alpha level of quality;
via "0", that the code is unreleased and precedes any test build we may spin.

We update the version number on stab before each test build we spin from that branch. For a beta, we set it to (final)b(n), where (final) represents the release identifier of the final release build and (n) represents the ordinal position of the build in the set of betas. For both release candidates and final release builds, we set the version to (final).

When What Can Land

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

In general, new features and enhancements to existing features can land only on dev, while bug fixes can land on dev, stab, or both.

New docs and docs enhancements that do not involve code changes, however, can land on stab during the first two weeks of each stabilization period, so tech writers have time to document late-breaking changes, and because such changes are less likely to cause regressions.

Landing Requirements

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

In order to land, a change must provide a notable benefit and not unintentionally change existing functionality (f.e. busting tests). In most cases, it must also pass a code review by an SDK code reviewer. And if it changes or adds a user-facing interface, including APIs implemented as CommonJS modules and command-line tools/flags, it must also pass an API/interface review by the technical lead.

Exceptions to the code review requirement include:

release management changes (f.e. version number bumps)
additions to the credits
obvious and trivial test bustage fixes
obvious and trivial typo (spelling, grammar) fixes in documentation

Rationale

Shipping frequently on a regular schedule, i.e. quality/date-driven or "train model" releases, gets improvements into users' hands faster and promotes developer productivity and code quality by reducing the stress and tunnel vision associated with its principal alternative (i.e. shipping infrequently and irregularly via quality/feature-driven releases).

Maintaining compatibility with new versions of Firefox is a key goal for the project to reduce the compatibility burden on addon developers and users alike, and we need be able to ship as often as Firefox to achieve it, since any Firefox release can contain a compatibility issue.

We don't provide APIs for new Firefox features before they ship in Firefox because it is difficult to align the two products' schedules to accommodate landing such APIs. However, we do want to release those APIs as soon as possible and will look for ways to make it happen (f.e. by making it possible to land such APIs into core Firefox alongside the features they expose).

Having two active (three total) branches keeps developers productive by avoiding freezes and other branch controls that prevent developers from integrating continuously on a central branch. Firefox uses three active (four total) branches (and thus four channels) for this reason, but our team is too small to justify the branch management burden of an additional branch, and our userbase is too small to fragment across four channels.

Releases every six weeks allow us to ship at least as often as Firefox, while twelve week cycles with six week overlaps let us work on just two active branches.

Two active branches instead of three mean we have to maintain compatibility with two versions of Firefox on the dev branch, but that is not an undue burden, because we already intend to maintain compatibility with older versions of Firefox (although it is unclear how far back we'll go).

We communicate versions, despite our rapid release schedule, because our developer audience understands them.

Our ratio of development to stabilization time (6/6) is significantly larger than Firefox's (6/12) but justified by our ability to isolate features (marking APIs/commands/options experimental, segregating functionality into separate modules/tools that must be explicitly invoked) and willingness to back stuff out.

(An alternative plan of four weeks of development, four weeks of alpha->beta stabilization, and four weeks of beta->release stabilization, with the alpha->beta stabilization split across the branches, would give us a 4/8 ratio, but it would mean branch controls for the last two weeks of each cycle on dev.)

References

Jetpack/Development Process

Contents

Release Schedule

Development Branches

Distribution Channels

Version Identifiers

When What Can Land

Landing Requirements

Rationale

References

Navigation menu

Jetpack/Development Process

Release Schedule

Development Branches

Distribution Channels

Version Identifiers

When What Can Land

Landing Requirements

Rationale

References

Navigation menu

Search