milestone plan updates

0 views
Skip to first unread message

Asa Dotzler

unread,
Apr 1, 2004, 9:58:30 PM4/1/04
to
It's been just about a year since we cut the 1.4 branch. In addition to
the normal Mozilla application suite milestone release, Firefox and
Thunderbird will be doing releases off of this branch -- including
Firefox 1.0 (!) and there are also major vendors planning releases to
coincide with with Mozilla 1.7. All of this lines up well for making 1.7
our next long-lived branch. To make these releases successful, we need
to focus on stability and data integrity bugs. To give ourselves the
time to make further improvements to our stability, drivers are making
some changes to the milestone plan.

Rough Schedule:

We're going to delay branching 1 week (to April 9). We'll be scheduling
three release candidates from the 1.7 branch, each 2 weeks apart, with
room for more if needed (first on or around April 14, second on April
28th, and final on April 12th). This means moving the 1.7 final release
date out 1 month from mid-April to mid-May.

Details:

Delaying the branching for 1.7 by about a week will give us some more
time to gather and respond to TalkBack data
<http://bugzilla.mozilla.org/show_bug.cgi?id=238446>, helping to
identify and fix crash bugs on the trunk where we have most of our QA
and testing resources. The QA community has been working to get the
crash buglist cleaned up as much as possible. To make 1.7 the most
stable release ever, we'll be looking for engineering help to knock off
as many of the reproducible, high-profile crashers as QA and TalkBack
resources can identify.

Shortly after branching (days) we will do the first of a series of 1.7
pre-releases to validate the much of stability work that's been
underway since 1.7 beta (we've already knocked off a significant number
of the 1.7 beta topcrashers). Because we tend to have somewhat fewer QA
and testing resources on branches, we'll be doing these release
candidates to keep the download, bug reporting, and Talkback volume
high. Previous long-lived branches have had three of these release
candidates and that seems like a reasonable approach for this branch.

Reply all
Reply to author
Forward
0 new messages