Add-on SDK dev process/release schedule
Myk Melez
It's time to plan post-1.0 Add-on SDK releases. Planning involves both
determining the development process/release schedule and deciding which
features to prioritize.
I've taken a first cut at a development process/release schedule that
employs the same "train" model as Firefox and aligns SDK releases with
Firefox releases.
This is just an initial draft, so it's subject to revision, and I'm keen
to get feedback. Is this a reasonable process and schedule? Will it help
us ship quality software on a regular basis, keeping our users happy and
development humming along? Let me know what you think.
Cheers,
-myk
Note: the canonical version of this document is on the Mozilla wiki:
https://wiki.mozilla.org/Jetpack/Development_Process
Jetpack Development Process
---------------------------
Goals
ship frequently on a regular schedule
maintain compatibility with new versions of Firefox
minimize the number of branches and channels
Non-goals
provide APIs for new Firefox features before they ship in Firefox
Process
We ship a stable SDK release every six weeks, with twelve week
development cycles on two active branches, a development branch (dev)
and a release branch (rel). Each release spends six weeks on dev and six
on rel, and work on consecutive releases overlaps by six weeks, so we
merge from dev to rel every six weeks, and we start working on each
release as soon as we merge our work on the previous one to rel. Thus
dev is never frozen (excepting bustage and server maintenance).
We have three distribution channels: dev, test, and release. The dev
channel is the repository; we don't produce dev builds. The test channel
is the discussion group; we produce alpha, beta, release candidate
(candidate), and final release (final) builds at least once a week and
announce them in the group. The release channel is the Add-ons Blog (and
other communications as appropriate); we announce final builds in the blog.
We don't provide automated updates to newer releases but may do so for
builds we push to the test and release channels in the future.
Feature development happens on the dev branch. It is subject to existing
quality controls (reviews, unit tests). 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).
Feature stabilization takes place on the rel branch. We merge to rel
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 the release some more and
prepare marketing materials.
We achieve quality goals by fixing bugs and cutting features.
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).
The branches look something like this:
https://wiki.mozilla.org/images/8/8a/Addon-sdk-branches.png
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.
Rel maintains compatibility with its accompanying Firefox release (i.e.
the one on Firefox's beta branch when rel ships). Dev maintains
compatibility with the next two Firefox releases (the ones on Firefox's
aurora and central branches when dev merges to rel).
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.
The schedule for the next few releases (and their accompanying Firefox
releases) looks like this:
https://wiki.mozilla.org/images/9/9d/Addon-sdk-schedule.png
TBD
where stabilization fixes land (on dev, then cherry-pick to rel, or
on rel, then merge to dev?)
whether rel is a single branch or a series of them, one per release
(if rel is a single branch, it may be easier to integrate with test
automation; if each release has its own rel branch, we don't have to cut
another branch to take a blocker fix after we release the candidate
build and merge dev to rel 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
Shipping frequently on a regular schedule, i.e. quality/date-driven or
"train model" releases, gets improvements into users' hands faster and
promotes developer productivity and code quality by reducing the stress
and tunnel vision associated with its principal alternative (i.e.
shipping infrequently and irregularly via quality/feature-driven releases).
Maintaining compatibility with new versions of Firefox is a key goal for
the project to reduce the compatibility burden on addon developers and
users alike, and we need be able to ship as often as Firefox to achieve
it, since any Firefox release can contain a compatibility issue.
We don't provide APIs for new Firefox features before they ship in
Firefox because it is difficult to align the two products' schedules to
accommodate landing such APIs. However, we do want to release those APIs
as soon as possible and will look for ways to make it happen (f.e. by
making it possible to land such APIs into core Firefox alongside the
features they expose).
Having two active branches keeps developers productive by avoiding
freezes and other branch controls that prevent developers from
integrating continuously on a central branch. Firefox uses three
branches (and thus four channels) for this reason, but our team is too
small to justify the branch management burden of a third branch, and our
userbase is too small to fragment across four channels.
Releases every six weeks allow us to ship at least as often as Firefox,
while twelve week cycles with six week overlaps let us work on just two
active branches.
Two branches instead of three mean we have to maintain compatibility
with two versions of Firefox on the dev branch, but that is not an undue
burden, because we already intend to maintain compatibility with older
versions of Firefox (although it is unclear how far back we'll go).
We communicate versions, despite our rapid release schedule, because our
developer audience understands them.
Our ratio of development to stabilization time (6/6) is significantly
larger than Firefox's (6/12) but justified by our ability to isolate
features (marking APIs/commands/options experimental, segregating
functionality into separate modules/tools that must be explicitly
invoked) and willingness to back stuff out.
(An alternative plan of four weeks of development, four weeks of
alpha->beta stabilization, and four weeks of beta->release
stabilization, with the alpha->beta stabilization split across the
branches, would give us a 4/8 ratio, but it would mean branch controls
for the last two weeks of each cycle on dev.)