> Development > Mozilla > Roadmap

mozilla development 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).

tree management

Here is a depiction of latest thinking on tree management:

release branching diagram

Changes from the last plan:

  1. A 5 week milestone cycle instead of 6 week, starting in 2001.
  2. A new Mozilla 0.7 release representing the best-build-of-December. There is no bugzilla target milestone or keyword for this release, as it is defined retrospectively by based on everyone's QA feedback.
  3. mozilla0.8 starts on 3-Jan and releases around 12-Feb.
  4. mozilla0.8.1 starts on the trunk on 9-Feb and releases around 19-Mar.
  5. mozilla0.9 starts after 16-Mar and releases around 23-Apr.
  6. mozilla0.9.1 (or 1.0 if we work hard and fortune smiles on us) starts on 20-Apr and releases around 28-May.
  7. We encourage Mozilla embedders to target 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 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).

how you can help

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 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.

code review 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 that have other policies set by module owners. All code hosted by 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.

project management

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, has created a group of project managers,

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 and -- better for scaling up to thousands of ideas -- your bugzilla milestone keyword nominations, thoughtful additional comments, and bug-targeting triage help are welcome.

Copyright © 1998-2001 The Mozilla Organization.
Last modified May 1, 2001.
Document History