![]() |
![]() |
![]() |
||||||||||||||||||||||||||||
![]() |
||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
Mozilla Roadmap Update: Moz 1.0 April Release Confirmed & Post-1.0 Development Plan AnnouncedMike Angelo -- 17 February 2002 (c)
The October 2001 Mozilla Development Roadmap was updated late yesterday. With some four calendar years and more than 1000 person-years in the making, it appears that AOL-Netscape's Mozilla Organization plans to release its Mozilla 1.0 application-programming framework and Web browser-suite this April. Additionally, Mozilla's chief technical lizard, Brendon Eich, has laid out the post Mozilla 1.0 development plan. Under the February 2002 Mozilla Development Roadmap update, there is a major change in the Mozilla milestone releases scheduling. Up through Mozilla 1.0, milestones have been released on a five-week development cycle. Starting with Milestone, 1.1, the Mozilla trunk-development cycle period will be thirteen weeks instead of the current five weeks. That means four major milestones per year. However, there still will be what in-effect is an approximately five-week milestone release schedule. That's because there will be an alpha and a beta release before each major milestone release. For example after Mozilla 1.0, the development plan calls for Mozilla 1.1 alpha, then 1.1 beta, and then Milestone 1.1. There also will be a Mozilla 1.0 development branch too. The Mozilla 1.0 branch will be for fixing Mozilla 1.0 bugs. The numbering schema on the Mozilla 1.0 development branch will take the form 1.0.1, 1.0.2, etc. Please see Figure 1.
Work on the Mozilla 1.1 alpha release is scheduled to start on 29 March 2002. Please see Figure 2.
Here is the explanation of the post Mozilla 1.0 plan as set forth in the Mozilla Organization's 16 February 2002 Mozilla Development Roadmap: 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.
Resources |
||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||