mozilla development roadmapBrendan Eich
Welcome to the Mozilla development roadmap. This document briefly describes where the Mozilla project has been, and then details where it is going. It proposes key "road rules" and a release schedule for ongoing Mozilla-the-browser source milestone releases, from which anyone can build commercial and other products. It also hints at how Mozilla-the-platform should evolve, again from an operational or "release process" point of view.
The original roadmap recorded the momentous decision in October 1998 to reset the Mozilla project around the new layout engine (now called Gecko), a cross-platform front end (XPFE; now several XP Apps built on an XP Toolkit), and a scriptable components architecture (XPCOM and XPConnect).
The previous roadmap charted Mozilla's path through the release of Netscape 6 and beyond, toward the goal of releasing a Mozilla 1.0 milestone. In that update, I wrote "Mozilla needs performance, stability, and correctness" and not any particular new feature. Just before 2001 began, I wrote that useful and relevant (defined by the community) extensions are always welcome, provided that they don't have a high opportunity cost in terms of contributors who otherwise could and would have helped hack on 1.0. But by the fall of 2001, as noted in the Mozilla 1.0 manifesto, the opportunity costs of features and extensions had grown to the point where such "non-1.0" work jeopardized a 1.0 milestone that fit into any achievable schedule.
This roadmap update reflects the milestone schedule for the summer of 2002, now that Mozilla 1.0 has been released.
Here is a depiction of the latest thinking on tree management:
In a departure from the five-week milestone cycle of 2001, each major milestone takes one quarter of a year or thirteen weeks to be delivered, and starts with a five-week "alpha" milestone, during which destabilizing development should be done. This is followed by a five-week "beta" milestone period during which less risky bug fixes, in particular followup and cleanup of the alpha phase work that tend to restabilize the codebase, should be targeted. Finally, a two to three week "done" period, where only driver-approved changes can be checked in, completes the milestone. There is enough slack to allow a floating holiday week per quarter, which we hope will help avoid the "time and people shortage" experienced last December, during 0.9.8.
Each milestone ends with a release to gather automatic crash reports ("talkback"). We believe that this feedback must be gathered and acted upon at least every five or six weeks, based on our several years' experience. We hope that alpha and beta milestones need no more than a few days' tree closure to prepare for release. As we do not intend to promote alpha and beta releases for uses other than testing, we will ship those releases according to the predetermined schedule, and let the chips fall where they may. Again, the once-per-quarter major release (e.g., 1.1) is the product-worthy branch-point.
Thus we hope to match the rhythm of the Mozilla community, which seems to have resulted in an odd-even pattern of "alpha-ness" and "beta-ness" observed since at least 0.9.1, along with a protracted freeze and branch effort before enough bugs were wrung out to release.
Finally, we are rationalizing our release numbering to count branches, with the leading 1 for the trunk version. Thus the 1.0.1 branch-of-a-branch sketched in the picture above, although at a date yet to be determined. The long-lived 1.0 branch should host conservative development of bug fixes that may also be appropriate for the trunk, per the Mozilla 1.0 manifesto's rationale,
Interested parties should collaborate, with support from firstname.lastname@example.org, in developing conservative fixes for critical bugs in this branch. Anyone who wants a baseline for development that will work with the public APIs of Mozilla 1.0 is free to develop against the 1.0 branch.
Tabulating the milestones to show the proposed dates, with trunk freeze, branch creation, and milestone release dates distinguished from one another (the next milestone's start date is the previous one's branch date), yields:
|milestone||start||freeze||branch||ideal release||actual release|
Traditionally, the milestone freeze time is 11:59 P.M. Pacific Time (see the tinderbox page for notices) on a Tuesday. During the freeze, only bugs deemed "must-fix-for-this-milestone", typically last minute regressions, are fixed on the trunk, as everyone tries to qualify the daily builds as branch-worthy. Release email@example.com create the milestone branch, which receives even more intensive QA over the weekend, leading to a release at the earliest by the following Wednesday.
We have tried, and sometimes failed, to avoid slipping any release, to avoid extending the life of a milestone branch and dividing labor poorly between trunk and branch. In spite of past difficulties, we aim to release by the Wednesday following the freeze, and use the "done" mini-milestone to absorb extra work that might cause an earlier slip. So, any not-quite-showstopper bugs unfixed by Wednesday should be targeted at the next Mozilla milestone and fixed ASAP.
Drivers have proposed these changes to the previous milestone plan in order to use "even more obvious" milestone numbers, to match the odd/even stability pattern and end-game schedule observed since 0.9.1, and to match calendar seasons and business quarters (with only a week's skew from the vernal equinox to when the 1.1alpha trunk should open). If you are planning a Mozilla-based product release whose schedule does not jibe well with the above milestones, we welcome your feedback (we will keep confidential information to ourselves, and will sign NDAs if necessary).
how you can help
Mozilla embedders: we need your input to Bugzilla, marking bugs
mozilla1.1, and other relevant keywords.
Mozilla project management will help ensure
that bugs are assigned to hackers who can target their fixes so as to satisfy
as many milestone-keyword nominations as possible.
Bug assignees, and especially helpers who can offload
or untargeted bugs from their nominal assignees and fix those bugs: please make
a pass at targeting your assigned bugs across the
mozilla1.2 milestones, using the criteria in the Mozilla 1.0 manifesto.
Please try to offload bugs to helpers, pinging
firstname.lastname@example.org if you cannot find
anyone to help fix futured or untargeted bugs that you believe should be fixed
Community members: please use the
nomination system wisely, and do not change the Target Milestone of anyone
else's bug without the assignee's consent.
The keyword-proposal/target-milestone-disposal system will continue beyond 1.0
to help inform prioritization by bug assignees.
You may of course vote for bugs also to help inform prioritization (but remember
that patching beats voting; also, please keep advocacy out of the bug system).
mozilla.org is continuing to require code review across the board to approve checkins to the bulk of the Mozilla codebase. The Mozilla Code Reviewers document distinguishes areas of code that require this so-called "super-review" from those hosted on cvs.mozilla.org that have other policies set by module owners. All code hosted by mozilla.org requires active ownership, and therefore module owner review of changes before a contributor can type 'cvs commit'.
To drive developers looking to help toward bugs needing assistance in a timely fashion, to moderate risk, and to aid commercial projects based on Mozilla in managing their product releases, mozilla.org has created a group of project managers, email@example.com.
The current drivers are:
- David Baron, firstname.lastname@example.org
- Chris Blizzard, email@example.com
- Peter Bojanic, firstname.lastname@example.org
- Scott Collins, email@example.com
- Asa Dotzler, firstname.lastname@example.org
- Brendan Eich, email@example.com
- Chris Hofmann, firstname.lastname@example.org
- Randell Jesup, email@example.com
- Robert O'Callahan, firstname.lastname@example.org
- Tim Rowley, email@example.com
- Mike Shaver, firstname.lastname@example.org
- Jud Valeski, email@example.com
- Dan Veditz, firstname.lastname@example.org
I hope, in the not too distant future, to update the
roadmap with some thoughts on the future of the Mozilla project after 1.0.
Clearly, bug fixes, architectural changes, and new code waved off from
mozilla1.0 will want to land during
Mozilla also needs to support the "Mozilla-the-platform" side of the coin for
more applications than the default-built browser/mailnews/editor/chatzilla
I hope too that Mozilla technologies and innovators can make significant
qualitative improvements (e.g., via something like
in how we all browse, organize, and cope with information on the web, in our
file systems, and locked into application data formats, wherever such data
There is life after 1.0 -- stay tuned!