draft of new release plan and schedule
Myk Melez
It's time to plan post-1.0 SDK releases. Here's my first cut at a plan and schedule, including proposed dates for the next three releases and the rationale for the plan being proposed.
This is just an initial draft, so it's subject to revision, and I'm keen to get your feedback. Is this the best way for the project to achieve our goals? Will it keep our users happy and development humming along? Let me know what you think!
Cheers,
-myk
Jetpack Release Plan and Schedule
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
Plan and Schedule:
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:
dev: ...-------------------------...
| | | |
rel: aabbccaabbccaabbcca...
| | |
f f f
1.1 1.2 1.3
(Note: each column in this graph represents a week of time, except that "|" and "f" represent points in time at which merges are performed and final builds produced; and "1.1", "1.2", and "1.3" represent final build versions.)
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:
m 000000000000000000000000000011111111111111
m 334444555556666777788888999900000111122222
d 220112011230122011200123012201123012201123
d 184296307417418529629630630730730630741851
SDK 1.0: bbbbbbbbbbcccf
Firefox 5: ---aaaaabbbbbf
Firefox 6: ------aaaaaabbbbbbf
SDK 1.1: -------aabbccf
Firefox 7: ------aaaaaabbbbbbf
SDK 1.2: ------aabbccf
Firefox 8: ------aaaaaabbbbbbf
SDK 1.3: ------aabbccf
Firefox 9: ------aaaaaabbbbbbf
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.)
Hernan Rodriguez Colmeiro
> 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.
>
I don't understand this. Today I received an email from AMO telling me
that my addons using the 1.0RC2 or newer would be automatically
updated to the 1.0 release when it is ready. Do you mean that addons
on AMO would be automatically updated to stable only if they're using
a test or release build, but not from stable to stable?
>
> 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).
>
You are talking about landing part of the SDK into Firefox itself?
Also, you mean that development of APIs for new Firefox features won't
begin until those features are shipped in a beta, in a final release
or landed on central?
I'm pretty excited about this new rapid release cycle, I think it'll
ease even more the maintenance of addons developed with the SDK!
Having the developer know in advance when to start looking into the
(not so) possible compatibility issues is a good thing.
Something that I think would be nice is having some kind of calendar
with release tracking. That way developers can check quickly what's
the status of the SDK in case they don't follow closely the releases.
Hernán
Myk Melez
> On Fri, Jun 17, 2011 at 16:48, Myk Melez<m...@mozilla.org> wrote:
>> 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.
> I don't understand this. Today I received an email from AMO telling me
> that my addons using the 1.0RC2 or newer would be automatically
> updated to the 1.0 release when it is ready. Do you mean that addons
> on AMO would be automatically updated to stable only if they're using
> a test or release build, but not from stable to stable?
notified when a new version of the SDK is available.
Addons on AMO are a different story. We are going to update those
automatically from stable to stable.
>> 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).
> You are talking about landing part of the SDK into Firefox itself?
> Also, you mean that development of APIs for new Firefox features won't
> begin until those features are shipped in a beta, in a final release
> or landed on central?
Yes, I'm talking about landing parts of the SDK into core Firefox. I'm
not sure when APIs for new Firefox features will be developed. In some
cases, they may be developed at the same time as the features
themselves. In other cases (f.e. your simple preferences API, which is
up for review right now), they may be developed shortly thereafter.
The message this passage is trying to convey is that we aren't going to
try to ship APIs for features before those features have shipped. We may
nonetheless succeed in doing so in such cases, and in the future we
might decide to try doing it intentionally, depending on whether we
think we can align the schedules well enough.
> Something that I think would be nice is having some kind of calendar
> with release tracking. That way developers can check quickly what's
> the status of the SDK in case they don't follow closely the releases.
Yup, a calendar is a good idea, although it might be best to add the
releases to a general planning calendar, so folks can see how SDK
releases line up with Firefox releases.
-myk
Myk Melez
I've put this draft on the wiki:
https://wiki.mozilla.org/Jetpack/Development_Process
And it has graphical charts!
Feel free to continue the conversation here. In the meantime, I also
posted it to dev.planning so folks there can comment on the proposal:
http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/a55ac7c6f3c21fe0#
-myk