Jetpack/Development Process: Difference between revisions

← Older edit

Jetpack/Development Process (view source)

Revision as of 08:07, 19 June 2012

2,964 bytes added , 19 June 2012

___________________________

Taewong

Confirmed users

235

edits

@@ Line 7: / Line 7: @@
 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.}}
+{{note|Further readings about the Firefox development and release process can be found here: [http://mozilla.github.com/process-releases/draft/development_overview/ overview], [http://mozilla.github.com/process-releases/draft/development_specifics/ specifics].}}
+The [[Jetpack/SDK_2012_Release_Schedule | 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 [[#SDK_Releases_and_Firefox_Compatibility | algorithm described below]].
-[[Image:Addon-sdk-schedule.png]]
+<h2>SDK Releases and Firefox Compatibility</h2>
-{{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.}}
+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.
+<h3>Firefox Versions</h3>
+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:
+<pre>
+Release     ->  X
+Beta        ->  Release
+Aurora      ->  Beta
+Development ->  Aurora
+            ->  Development
+</pre>
+The [[RapidRelease/Calendar|Rapid Release Calendar]] shows what this looks like for the second half of 2011 and the first half of 2012.
+<h3>SDK Versions</h3>
+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 [https://github.com/mozilla/addon-sdk GitHub] (beta+1)
+As for Firefox, every 6 weeks a new SDK is released, and everyone moves along.
+<pre>
+Release     ->  X
+Beta        ->  Release
+Development ->  Beta
+            ->  Development
+</pre>
+'''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 =
@@ Line 21: / Line 76: @@
 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.
+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 =
@@ Line 44: / Line 99: @@
 = Landing Requirements =
-{{draft|}}
 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.
@@ Line 58: / Line 111: @@
 * release engineering changes (f.e. version number bumps)
-* additions to the [https://addons.mozilla.org/en-US/developers/docs/sdk/latest/dev-guide/appendices/credits.html credits]
+* 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 [https://tbpl.mozilla.org/?tree=Jetpack&usetinderbox=1 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 =