Jetpack/Development Process

	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.

Goals

• ship frequently on a regular schedule
• maintain compatibility with new versions of Firefox
• minimize the number of branches and channels

Non-goals

• provide APIs for new Firefox features before they ship in Firefox

Process

We ship a stable SDK release every six weeks, with twelve week development cycles on two active branches, a development branch (dev) and a release branch (rel). Each release spends six weeks on dev and six on rel, and work on consecutive releases overlaps by six weeks, so we merge from dev to rel every six weeks, and we start working on each release as soon as we merge our work on the previous one to rel. Thus dev is never frozen (excepting bustage and server maintenance).

We have three distribution channels: dev, test, and release. The dev channel is the repository; we don't produce dev builds. The test channel is the discussion group; we produce alpha, beta, release candidate (candidate), and final release (final) builds at least once a week and announce them in the group. The release channel is the Add-ons Blog (and other communications as appropriate); we announce final builds in the blog.

We don't provide automated updates to newer releases but may do so for builds we push to the test and release channels in the future.

Feature development happens on the dev branch. It is subject to existing quality controls (reviews, unit tests). We may introduce additional quality controls in the near future (f.e. a requirement that new features and enhancements initially be marked experimental and be isolated from non-experimental use of the product).

Feature stabilization takes place on the rel branch. We merge to rel right after we ship the final build for the previous release. The stabilization period lasts six weeks and comprises three two week periods: alpha, beta, and candidate. During the alpha period, we address beta blockers, raising quality to the beta level. During the beta period, we address release blockers, raising quality to the release level. During the candidate period, we bake the release some more and prepare marketing materials.

We achieve quality goals by fixing bugs and cutting features.

Releases have versions 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).

The branches look something like this:

SDK releases precede the Firefox releases they accompany by enough time for us to repackage AMO-hosted addons with the SDK release but not by too much time to prevent us from tracking and addressing compatibility issues.

Rel maintains compatibility with its accompanying Firefox release (i.e. the one on Firefox's beta branch when rel ships). Dev maintains compatibility with the next two Firefox releases (the ones on Firefox's aurora and central branches when dev merges to rel).

The next SDK release after 1.0 is 1.1, and it accompanies Firefox 7 (skipping 6). Its schedule is slightly irregular to accommodate that target. If SDK 1.0 is found to be incompatible with Firefox 6, we address it in a 1.0.1 release branched from the 1.0 tag.

The schedule for the next few releases (and their accompanying Firefox releases) looks like this:

TBD

• where stabilization fixes land (on dev, then cherry-pick to rel, or on rel, then merge to dev?)
• whether rel is a single branch or a series of them, one per release (if rel is a single branch, it may be easier to integrate with test automation; if each release has its own rel branch, we don't have to cut another branch to take a blocker fix after we release the candidate build and merge dev to rel for the next release)
• how many weeks to precede each Firefox release (two? three?)
• conditions under which to increment the major number
• how to identify, and when to increment, the version in manifests, code, and docs on the two branches
• when to drop compatibility with older releases of Firefox

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 branches keeps developers productive by avoiding freezes and other branch controls that prevent developers from integrating continuously on a central branch. Firefox uses three branches (and thus four channels) for this reason, but our team is too small to justify the branch management burden of a third 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 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.)