Confirmed users
235
edits
Jetpack/Development Process: Difference between revisions
Jump to navigation
Jump to search
___________________________
(add a bunch more relevant references) |
(___________________________) |
||
| (12 intermediate revisions by 4 users not shown) | |||
| Line 5: | Line 5: | ||
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 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 | 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: [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]]. | |||
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 | <h2>SDK Releases and Firefox Compatibility</h2> | ||
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 = | |||
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. | |||
[[Image:Addon-sdk-branches.png]] | [[Image:Addon-sdk-branches.png]] | ||
| 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. | 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 | 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 = | = Distribution Channels = | ||
| Line 43: | Line 98: | ||
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). | 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 | |||
* release | |||
* additions to the | |||
* obvious and trivial test bustage fixes | * obvious and trivial test bustage fixes | ||
* obvious and trivial typo (spelling, grammar) fixes in documentation | * 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 = | = Rationale = | ||