> Development > Mozilla > Roadmap
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.
See the roadmap FAQ for up-to-the-minute answers to frequently-asked questions.
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. I want to make clear here 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.
This roadmap update refines the milestone schedule for calendar year 2001,
and calls for community help in defining Mozilla 1.0 via
bugzilla mozilla1.0
milestone keyword nominations on open bugs.
Remember, community members who can edit bugs should nominate by setting
the mozilla1.0 keyword, not by setting the bug's Target
Milestone (which belongs to the bug assignee).
Here is a depiction of latest thinking on tree management:
Changes from the last plan:
mozilla0.8 starts on 3-Jan and releases around 12-Feb.
mozilla0.8.1 starts on the trunk on 9-Feb and releases around
19-Mar.
mozilla0.9 starts after 16-Mar and releases around 23-Apr.
mozilla0.9.1 (or 1.0 if we work hard and fortune smiles on us)
starts on 20-Apr and releases around 28-May.
mozilla0.9.1 as their
"beta release" milestone.
As usual, each milestone ends with a short tree closure period, during which a branch is cut for QA and "must-fix" stabilization work. When the milestone is "done", we tag sources, upload binaries, and announce the release.
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 |
|---|---|---|---|---|---|
mozilla0.8 |
3-Jan-2001 | 7-Feb-2001 | 9-Feb-2001 | 12-Feb-2001 | 15-Feb-2001 |
mozilla0.8.1 |
9-Feb-2001 | 14-Mar-2001 | 16-Mar-2001 | 19-Mar-2001 | 26-Mar-2001 |
mozilla0.9 |
16-Mar-2001 | 18-Apr-2001 | 20-Apr-2001 | 23-Apr-2001 | 7-May-2001 |
mozilla0.9.1 (or 1.0?) |
20-Apr-2001 | 23-May-2001 | 25-May-2001 | 1-Jun-2001 | ? |
Traditionally, the milestone freeze time is 12 A.M. on a Wednesday. 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 staff@mozilla.org create the milestone branch, which receives even more intensive QA over the weekend, leading to a release the following Monday. We have tried to avoid slipping any release, to avoid extending the life of a milestone branch and dividing labor poorly between trunk and branch. Any not-quite-showstopper bugs unfixed by Monday should be targeted at the next Mozilla milestone and fixed ASAP.
Recent experience has shown that while we can branch by Friday after the
Wednesday (for practical purposes, Tuesday night) freeze, bug assignees cannot
thereafter fix most of the remaining several dozens of bugs by the next Monday.
Worse, the mozilla0.9 bugs unfixed when that release's branch was cut
could not be left unfixed in a milestone release: most were stop-ship.
Therefore, the mozilla0.9.1 ideal release date has been moved to
6-Jun-2000.
We hope this is a more accurate prediction, even if it's less ideal.
Drivers will work to reduce risk of
slips by identifying and escalating "long pole" bugs earlier in each milestone.
Drivers propose these changes to the last roadmap's plan in order to use "more obvious" milestone numbers, to pick up the pace slightly (5 weeks instead of 6), and to align better with several known commercial contributors' tentative release plans. 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).
Mozilla embedders: we need your input to bugzilla, marking bugs
with embed, footprint, mlk, perf,
mozilla0.8.1, mozilla0.9, 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 Futured
or untargeted bugs from their nominal assignees and fix those bugs: please make
a pass at targeting your assigned bugs across the mozilla0.8.1 and
mozilla0.9 milestones.
As you make progress, consider targeting mozilla0.9.1 as well.
And please do offload bugs to helpers, pinging
drivers@mozilla.org if you cannot find
anyone to help fix your futured or untargeted bugs.
Community members: please use the mozilla1.0 milestone-keyword
nomination system wisely, and do not change the Target Milestone of anyone
else's bug without the assignee's consent.
This keyword-proposal/target-milestone-disposal system will help decide whether
mozilla0.9.1, mozilla0.9.2, or a later 0.9.x release deserves
to be branded "Mozilla 1.0".
You may of course vote for bugs as usual, to help inform prioritization.
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'.
Design review obviously should precede code review! Use the porkjockeys mailing list (which has a news gateway) to raise design questions and issues.
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, drivers@mozilla.org.
The current drivers are:
Please see the draft "Mozilla 1.0"
definition document,
which will be supplemented and revised based on bugzilla mozilla1.0
keyword nominations and other input from the community.
Your ideas to drivers@mozilla.org and -- better for scaling up to thousands
of ideas -- your bugzilla milestone keyword nominations, thoughtful additional
comments, and bug-targeting triage help are welcome.