Labs/Jetpack/Process: Difference between revisions

From MozillaWiki
< Labs‎ | Jetpack
Jump to navigation Jump to search
No edit summary
 
Line 1: Line 1:
Development cycles last about four weeks, starting with three weeks of open development and concluding with at least one week of stabilization. During open development, all checkins are allowed. During stabilization, checkins are restricted to release blockers, low risk fixes, polish, and localizations.
This document describes the development process for Add-on SDK.


(The stabilization period is also an opportunity to prepare release announcements, finalize documentation, incorporate localizations, and do other release-related work.)
Development cycles last about four weeks, starting with about three weeks of open development and concluding with about a week of stabilization.


Release drivers meet once per week during open development and once per day during stabilization to triage (prioritize, target, assign) bugs, discuss issues raised in fora that haven't been filed as bugs yet, and keep up with release-related work that isn't tracked in bug reports (like the writing of release announcements).
During open development, general checkins are allowed. During stabilization, checkins are restricted to release blockers, low-risk polish fixes, and localizations.


During the stabilization period, once release blockers are resolved, we build a release candidate and release it to testers. As additional blockers are found and their fixes land during stabilization, we build and release additional such candidates.
We typically thaw the tree for open development on a Monday, freeze the tree for stabilization three weeks and two days later on Wednesday morning at 11am PT (19:00 UTC in the winter, 18:00 UTC in the summer), release the first release candidate that day, thaw the tree for the next cycle of open development the following Monday, and release the following Wednesday.


On the first day after the end of the stabilization period, or after the most recent release candidate has baked for at least two days without us finding additional blockers (whichever comes later), we release the most recent release candidate as the final release.
To ensure each release is well baked, we typically release no sooner than a week after the freeze and two days after the last release candidate.


(After a final release, we release minor updates to the most recent stable version as needed to address security vulnerabilities, major regressions, and other significant bugs. Minor updates are also an opportunity to incorporate polish and late-landing localizations, although those aren't impeti for the updates.)
We use numerically consecutive version numbers to identify releases. These started at 0.1 and continued through 0.9 before we released 1.0b1, the first beta version of what we expect to become a stable 1.0 release. They will continue with 1.0b2, 1.0b3, etc. until the stable 1.0 release.


We branch the tree after we release the final release.
During open development, the code in the repository is identified as the next expected version with the suffix "pre" appended to it, f.e. the code leading up to the 1.0b3 release is identified as 1.0b3pre.


(Alternately, we branch the tree at the beginning of the stabilization period, giving developers who are not on the hook for stabilization fixes an extra week of open development; or we branch it at some point during the stabilization period when it seems likely that we've resolved all release blockers.)
Release candidates use the final release version internally (i.e. in all code, documentation, and other files inside the package) and that version followed by "rc" and the number of the candidate (f.e. 1.0b3rc1) in references external to the package (f.e. in the names of the packages).
 
At the end of each open development period, drivers evaluate progress against a set of 1.0 criteria (to be determined). If we've achieved the 1.0 goals, drivers renumber the release to be 1.0 (which may require a longer than normal stabilization period). Otherwise the release is numbered with the next consecutive integer minor number (i.e. 0.8, 0.9, 0.10, 0.11, etc.).
 
(Optional: after each of the three weeks of open development, we release testing builds incorporating the latest changes.)

Latest revision as of 18:05, 2 February 2011

This document describes the development process for Add-on SDK.

Development cycles last about four weeks, starting with about three weeks of open development and concluding with about a week of stabilization.

During open development, general checkins are allowed. During stabilization, checkins are restricted to release blockers, low-risk polish fixes, and localizations.

We typically thaw the tree for open development on a Monday, freeze the tree for stabilization three weeks and two days later on Wednesday morning at 11am PT (19:00 UTC in the winter, 18:00 UTC in the summer), release the first release candidate that day, thaw the tree for the next cycle of open development the following Monday, and release the following Wednesday.

To ensure each release is well baked, we typically release no sooner than a week after the freeze and two days after the last release candidate.

We use numerically consecutive version numbers to identify releases. These started at 0.1 and continued through 0.9 before we released 1.0b1, the first beta version of what we expect to become a stable 1.0 release. They will continue with 1.0b2, 1.0b3, etc. until the stable 1.0 release.

During open development, the code in the repository is identified as the next expected version with the suffix "pre" appended to it, f.e. the code leading up to the 1.0b3 release is identified as 1.0b3pre.

Release candidates use the final release version internally (i.e. in all code, documentation, and other files inside the package) and that version followed by "rc" and the number of the candidate (f.e. 1.0b3rc1) in references external to the package (f.e. in the names of the packages).

Retrieved from "https://wiki.mozilla.org/index.php?title=Labs/Jetpack/Process&oldid=281758"