Jetpack/Development Process: Difference between revisions

Jetpack/Development Process (view source)

Revision as of 23:42, 27 September 2011

356 bytes removed , 27 September 2011

incorporate update to version on dev after merge to stab; spin only test builds; and be compatible with current and upcoming Firefox releases. also note proposed three week offset from Firefox release

MykMelez

canmove, Confirmed users

2,056

edits

@@ Line 1: / Line 1: @@
-= Goals =
+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 [[Labs/Jetpack/Release|Release Process]].
-* ship frequently on a regular schedule
+= Release Schedule =
-* maintain compatibility with new versions of Firefox
-* minimize the number of branches and channels
-= Non-goals =
+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).
-* coordinate dependencies between products such that
+We release each SDK version two ([https://groups.google.com/forum/#!topic/mozilla-labs-jetpack/e0RkE4zW9ew proposed: 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.
-** the SDK ships APIs for new Firefox features before the features ship in Firefox
-** Firefox ships support for new SDK features at the same time the features ship in the SDK
-= Process =
+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.
-We ship a stable SDK release on a regular schedule every six weeks. Each release undergoes six weeks of development and six of stabilization, so a complete cycle lasts twelve weeks, and release cycles overlap by six weeks (while one release is stabilized, the next one is developed).
+SDK 1.0's schedule did not follow this process. SDK 1.1's schedule was slightly irregular.
-We commit code to 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 open development on dev, after which it is merged to stab; continuing with six weeks of restricted stabilization on stab, after which it is merged to rel; and concluding with six weeks of statis on rel.
+[[Image:Addon-sdk-schedule.png]]
-We distribute code to three distribution channels: an unstable development channel (dev), a semi-stable test channel (test), and a stable release channel (rel). The dev channel is the code repository itself; we don't produce dev builds. The test channel is the project discussion group; we produce alpha, beta, release candidate (candidate), and final release (final) builds at least once per week and announce them in the group. The rel channel is the Add-ons Blog (and other communications, as appropriate); we announce final builds in the blog.
+= Development Branches =
-We don't provide automated updates to newer releases, but we may do so in the future.
+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.
+[[Image:Addon-sdk-branches.png]]
-Feature development happens on the development branch. It is subject to quality controls (reviews, unit tests, etc.). 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).
+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.
-Feature stabilization takes place on the stabilization branch. We merge to stab 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 and prepare the release.
+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.
-We achieve quality goals by fixing bugs and cutting features.
+= Distribution Channels =
-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).
+We distribute code to three distribution channels: an unstable development channel, a semi-stable test channel, and a stable release channel.
-The branches look something like this:
+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.
-[[Image:Addon-sdk-branches.png]]
+We don't provide automated updates to newer releases, but we may do so in the future.
-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.
+= Version Identifiers =
-Stab maintains compatibility with its accompanying Firefox release (i.e. the one on Firefox's beta branch when the SDK release ships). Dev maintains compatibility with the next two Firefox releases (the ones on Firefox's aurora and central branches when dev merges to stab).
+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).
-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.
+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:
-The schedule for the next few releases (and their accompanying Firefox releases) looks like this:
+* 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.
-[[Image:Addon-sdk-schedule.png]]
+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 =
@@ Line 47: / Line 47: @@
 {{draft|}}
-In general, new features and enhancements to existing features can land only on the development branch, while bug fixes can land on the development branch, the stabilization branch, or both.
+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 the stabilization branch during the first two weeks of each stabilization period (i.e. while the code is in alpha), so tech writers have time to document late-breaking changes, and because such changes are less likely to cause regressions.
+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 =
@@ Line 63: / Line 63: @@
 * obvious and trivial test bustage fixes
 * obvious and trivial typo (spelling, grammar) fixes in documentation
-= TBD =
-* where stabilization fixes land (on dev, then cherry-pick to stab, or on stab, then merge to dev?)
-* whether stab is a single branch or a series of them, one per release (if stab is a single branch, it may be easier to integrate with test automation; if each release has its own stab branch, we don't have to cut another branch to take a blocker fix after we release the candidate build and merge dev to stab 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 =