Jetpack/Development Process

From MozillaWiki
Jump to: navigation, search

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.

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.
Note: Further readings about the Firefox development and release process can be found here: overview, specifics.

The Add-on SDK 2012 Release Schedule shows the SDK releases we expect to see in 2012, and shows the range of compatible Firefox versions in a tooltip.

Note that this range is not fixed for a given SDK version, but changes as an SDK goes through Development and Beta states, and as the set of available Firefox versions changes, according to the algorithm described below.

SDK Releases and Firefox Compatibility

Each SDK is compatible with a particular range of Firefox versions: meaning that it's tested against those versions, and add-ons it produces will be marked as compatible with those versions.

Firefox Versions

At any time, there are four Firefox versions that matter:

  • Release
  • Beta (release+1)
  • Aurora (beta+1)
  • Development version on moz-central (aurora+1)

Every 6 weeks, a new Firefox is released, and everyone moves along: 

Release     ->  X
Beta        ->  Release
Aurora      ->  Beta
Development ->  Aurora
            ->  Development

The Rapid Release Calendar shows what this looks like for the second half of 2011 and the first half of 2012.

SDK Versions

The SDK release process mirrors that for Firefox, except that the SDK does not have separate Aurora and Beta states. So with the SDK we have three interesting versions at any given time:

  • Release
  • Beta (or Stabilization)(release+1)
  • Development version on GitHub (beta+1)

As for Firefox, every 6 weeks a new SDK is released, and everyone moves along. 

Release     ->  X
Beta        ->  Release
Development ->  Beta
            ->  Development

SDK Development Version An SDK in the Development state is compatible with all four of the current Firefox versions. Each time a new version of Firefox is released, the SDK drops compatibility with the previous release of Firefox.

SDK Released Version An SDK in the Release state is compatible with the Release Firefox and the Beta Firefox at the time of the SDK's release.

So: 1.4 ships on January 10th 2012. At that time, the released Firefox will be 9, and the Beta will be 10. Therefore 1.4 will support Firefoxes 9 and 10.

SDK Beta/Stabilization Version An SDK in the Stabilization state is compatible with the same Firefox versions as it will be compatible with in Release, plus any earlier versions still in existence.

So as long as Firefox 8 is still the current Release, and Firefox 9 is the Beta, and 10 is Aurora, then SDK 1.4 in Stabilization supports 8, 9, 10. Once Firefox 9 is released, halfway through the stabilization of SDK 1.4, Stabilization drops support for Firefox 8.

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 stasis on rel.

Addon-sdk-branches.png

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 all current Firefox 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).

Landing Requirements

New features and enhancements to existing features can land only on dev, except that new docs and docs enhancements can land on stab during the first three 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.

Bug fixes can land on dev, stab, or both. Fixes for bugs that affect both dev and stab should land on dev and then get cherry-picked to stab. (In the future we may land such changes on stab and merge them to dev.)

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

The bar for changing supported functionality is very high, and landings must not do so except for very good reason and along with every reasonable effort, in documentation and otherwise, to ameliorate the impact on existing users. The bar for changing internal and experimental functionality is lower, and landings can do so as appropriate.

In most cases, landings must also pass review by an SDK reviewer. Exceptions to the review requirement include:

  • release engineering 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

After landing a change, the committer must check the test automation dashboard to verify the change does not cause a test regression. Regressions must be resolved by fixing the bug causing the regression or reverting the change.

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

Retrieved from "https://wiki.mozilla.org/index.php?title=Jetpack/Development_Process&oldid=442783"