Mozilla 1.1alpha Plans

Thursday May 30th, 2002

David Baron has posted a Mozilla 1.1alpha update to netscape.public.mozilla.seamonkey. He notes that the release has slipped a bit due to work on the 1.0 branch and that is anxious to prevent any further delays. Therefore, the freeze for 1.1alpha will occur at midnight Pacific Daylight Time on Wednesday 5th June. The Roadmap has been updated to reflect the slippage.

#21 Re: Re: Confusing release numbers

by asa <>

Friday May 31st, 2002 4:42 PM

You are replying to this message

"Realistically, if 1.1 alpha is frozen right now, it is going to be a pretty uninteresting release. "

Either you misunderstand what the 1.1alpha, beta and final cycle will look like or you're of a very different opinion than the people working to make these Mozilla Milestones happen.

If you do understand the release cycles then I take exception with your definition of uninteresting. We've fixed nearly 2000 bugs in the 1.1alpha cycle, over 1000 that were not also fixed on the 1.0 branch. We've taken new features including "download manager", "view HTML mail as plaintext", "quote original message", windows and linux accessibility improvements, and much more <http://bugzilla.mozilla.o…,123563,30888,98476,97055> covers a handful of them. And we've taken heavy lifting changes, redesigns, rewrites and other major landings like the reflow coalescing and XUL fastload performance changes and more <http://bugzilla.mozilla.o…39471,112064,92033,135395> lists a couple of those. All of these changes warrant Milestone testing.

The people working hard to implement and test these changes do consider them interesting and the companies shipping products based on Mozilla technologies also consider them interesting.

"Users now have a solid release to use for a while so there's no point on insisting on stabilizing the development build even before the previous version is released."

(You've contacted all of organizations and individuals using and shipping Mozilla-based products and none of them are interested in something stable with the many changes mentioned above?) Spending months and months in an unstable state is neither good for our code, our distributors/vendors nor good for our testing community. We've been doing this for a few years now and have a pretty good idea about how quickly we can integrate and test new changes. The cycles in the roadmap reflect our collective experience developing, testing and delivering our technologies so it is unlikely that they're going to be tossed aside because someone is of the opinion that 1.1 is uninteresting.

Armchair project management is easy. If you think that you can put together a project that will have greater success then be my guest. Untold numbers of contributing organizations and individuals await your instructions.

"Wait for the reviews of mozilla 1.0 and netscape 7.0, reflect on that for a while and set some new development goals and then after a few months come with a 1.1alpha"

Wait for months? Just sit around and do nothing for months until c|net gets a copy of Netscape 7? What you fail to realize or acknowledge is that we've been working on 1.1alpha for a while now, taking thousands of checkins. We did reflect, for many months. We reflected on 0.9.6 and 0.9.7 and 0.9.8 and 0.9.9 and 1.0RC1 and 1.0RC2 and 1.0RC3, all the while making decisions to push certain features and other heavy lifting out to 1.1. Now we've taken those large changes and new features in 1.1alpha and they need to be fully tested in a Milestone. If now is too soon for you then you can ignore the release of 1.1alpha and 1.1beta milestones and not look again until we're at 1.1final. If we're moving too fast for your taste and you really want to be surprised by a new and exciting product then maybe you should ignore all the Mozilla Milestones and wait for Beonex 1.0 or Netscape 8. Users of these products can be surprised when they ship with a bunch of new features. It's much harder for Mozilla testers who can see changes as often as many times a day.

Release early and release often. We've been doing it since the beginning and we'll continue to do so. There have been more than enough interesting changes to get builds out to a wider testing audience and collect the kind of expanded feedback that we get from Mozilla Milestones.