canmove, Confirmed users
2,056
edits
Jetpack/Development Process: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
|||
| Line 43: | Line 43: | ||
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 = | ||
{{draft|}} | {{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. | |||
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. | |||
Exceptions to the | 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) | * release engineering changes (f.e. version number bumps) | ||
* additions to the [https://addons.mozilla.org/en-US/developers/docs/sdk/ | * additions to the [https://addons.mozilla.org/en-US/developers/docs/sdk/latest/dev-guide/appendices/credits.html credits] | ||
* 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 | ||