You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.
This page provides information on the next Mozilla release under construction. It includes links to key Bugzilla and Bonsai queries to track progress and describe where we are in the release process.
Each Mozilla release is broken up into three parts, an alpha cycles, a beta cycle, and a final cycle. Alpha development focuses on feature work. Beta development focuses on cleanup and general bug fixing. The final cycle is limited to very low-risk changes and fixes for more severe bugs and regressions missed during alpha and beta.
If your organization is depending on a particular Mozilla release and specific bug fixes or a specific timeframe, you should be in contact with drivers@mozilla.org.
| 12-Dec-2003 | The Mozilla 1.7a release cycle begins -- focus on important bugs and features |
| 4-Feb-2004 | Drivers start meeting daily to assess alpha blockers and evaluate approval requests |
| 11-Feb-2004 | Development freeze for Mozilla 1.7 Alpha |
| 16-Feb-2004 | Release of Mozilla 1.7 Alpha |
| 16-Feb-2004 | Start of Beta development period -- focus on cleanup |
| 5-Mar-2004 | Massive Beta Planning Blow Out Cantina (MBPBOC)- Drivers meet to take inventory of any large work pending, assess Beta stopper list and previouly minused bugs, and schedule remainder of release cycle. |
| 03-Mar-2004 | Announce upcoming Beta freeze to newsgroups/tinderbox |
| 10-Mar-2004 | Beta freeze |
| 15-Mar-2004 | Release of Mozilla 1.7 Beta |
| 15-Mar-2004 | Localization string freeze - String changes after this point are expensive |
| 2-Apr-2004 | Scheduled to branch and open the trunk for 1.8 (MOZILLA_1_7_BRANCH) |
Quarterly localization conference call/IRC meeting(s)postponed |
|
| Friday, June 11 at 8am PDT | |
| Thursday, June 10 at 6PM PDT | |
| 23-Apr-2004 | First test/release candidate completed |
| 14-May-2004 | Second test/release candidate completed |
| 07-Jun-2004 | Mozilla 1.7 RC3 |
| 15-June-2004 | Mozilla 1.7 |
| +1 Days | Completed language packs eligible for shipment on Mozilla CDs |
| +3 Days | CD manufacturing begins |
| +10 Days | CDs begin shipping |
All effort should be made to identify problems and come up with fixes as early as possible in alpha and beta cycles. When regressions and key problems are spotted at the end of release cycles drivers depend on the development and testing community to help identify changes that are needed to make release successful, and better than the previous release. Nominiations for release stoppers should focus on regressions, bugs with patches that have been tested and reviewed, and when possible high reward, low risk changes.
Testers should use the "blocking?" flag in bugzilla to nominate a bug as a release blocker. Drivers will evaluate these nominations and set the flag to either "+" or a "-" indicating that the bug is indeed a blocker for the release or that the bug will not block the release.
An "approval?" patch flag is used to request approval to check in a reviewed patch to the release during the drivers' managed lock down. Drivers evaluate these requests and set the flag to either a "+" or a "-" More information on flags...
Testing of all the changes that are taken near the end of every development cycle are key to develivering succesfull releases. The following queries identify bugs "fixed"and bugs "verified" near the end of the release. Testers can help by getting involved in testing and verifying bugs on listed in the following Bugzilla Queries.
We're working hard to make it easier for those building Mozilla localizations. With the release of the Beta, all localizable strings within the Mozilla application suite are frozen. On rare occasions it will be necessary to make a change which will impact Mozilla localizations. If that happens, drivers will announce the change on the appropriate newsgroups as well as flag the bug in question with the keyword "late-l10n".
While it's difficult to construct a simple query which 100% accurately reflects the changes that have been made to Mozilla in a given release cycle, close approximations aren't so hard to get. For visibility into what's changed during the cycle, Bonsai and Bugzilla are your best bets.
As mentioned above, drivers@mozilla.org are using two types of flags to manage releases, bug flags and patch flags.
The first type, the bug flag (appears on the bug under the Cc: section) and currently looks like "blocking1.7[? + -]". You'll see this flag on all of the Browser and MailNews bugs (including NSPR, NSS, PSM and Directory) and it is used to nominate a bug to drivers@mozilla.org. We used to do this with a keyword or a tracking bug.
To nominate a bug as blocking a release you set the flag to "blocking1.7?". The "?" is the request that drivers evaluate this bug as a 1.7 Alpha blocker. Drivers will mark the bug as "blocking1.7+" if they would hold the release for that bug. Drivers will mark the bug "blocking1.7-" if they would not hold the release for that bug. A bug which is marked with a "-" does not indicate that drivers don't want the fix or that it's not worth fixing. It just indicates that drivers wouldn't hold up a release for that issue.
The second type of flag is a patch flag (also called an attachment flag). When we are in a development freeze, as indicated by the red sections in the development roadmap, you'll see the flag "approval1.7[? + -]" listed in the patch manager under the "review[? + -]" and "superreview[? + -]" flags. The approval flags are used to request approval to land a patch during the driver-managed milestone closure periods and on driver-managed branches. We used to manage approvals with email but the volume made that process impractical.
To request approval for a patch that needs to land on the driver-managed 1.7 tree, go to your patch, set the flag to "approval1.7?" and add a comment in the comment box explaining the importance of landing the patch, the risk associated with the fix, and the testing that's been done. If drivers@mozilla.org agree that the patch is important to the branch/release then the flag will be set to "approval1.7+". This denotes explicit permission to land the patch. If you get approval please land at the first open tree opportunity. Drivers will mark the patch as "approval1.7-" if they do not want the patch to land for this release.