Update on Tree Plan for 0.9.4
Saturday August 25th, 2001
Asa Dotzler has sent in an update to what mozilla.org's plans are for the 0.9.4 milestone. Click the full article link for more info on this, and what you can do to help.
#53 he's a troll but there's some truth in his stuff
Tuesday August 28th, 2001 5:57 AM
You are replying to this message
He's a troll but there's some truth in his stuff. I recall discussions about mozilla 1.0 dating back to early 2000. At the time saying that a 1.0 would be a year away was seen as pessimistic (in retrospect it turned out to be overly optimistic). When netscape released 6.0 in august 2000, it was generally believed that a 1.0 was long overdue and probably close.
We're a year past that now and still no 1.0. The roadmap has been updated a few times since. The current one predicts that a 1.0 release is close. However, I'll believe it when I see it.
The current milestone is actually pretty usable. I would call it worthy of a beta and I disapprove of netscape using an even older build for a release. It's just not ready.
I think the mozilla developers agree with me on this (otherwise they would call it a 1.0). In the past there have been discussions here on what is alpha/beta. As I recall beta qualifies as feature complete with a reasonable level of stability. That's mozilla right now.
So, what is the importance of a 1.0?: - Communicates to the outside world that it is ready for usage. Only users who know what they are doing are willing to use pre 1.0 builds of software. - Gives the developers room to start working on a 2.0 version. Right now any new code that breaks current code is discouraged, this slows down progress. - Gives third party developers something solid to build on instead of a relatively stable build with an unclear status. It would be nice to see stuff from mozdev maturing, a 1.0 release is needed for that.
Right now mozilla does all it is supposed to do, it just needs to do it a bit better and more reliable.
My advice to the mozilla developers: After 0.9.4 call a complete feature freeze and take three months to eliminate bugs, polish the GUI, document the project and do some hardcore quality testing. Then call it a 1.0. When close to the release, have release candidates and advertise their existence so that you get lots of feedback.
Realistically, you need that amount of time to release a properly tested product of this size. If you take less time you end up with another "it may work for you but you're on your own" type of build.
After 1.0, plan 1.0.1 (e.g. a month after release 1.0), 1.1 (e.g. 6 months after 1.0) and next versions and allow for similar testing periods before a final release. And for heaven's sake, produce a roadmap that is actually realistic rather than a "we'll see what happens" list of meaningless versions.
I suggest a similar release schedule as the linux kernel would be appropriate: odd numbers for development and even numbers for releases.