The other thing to consider is everyone seems to have one more fix they'd like to get in. If we waited for everyone to be happy, we literally would never be able to have a release. At some point we have to draw the line and ship. The 0.9.4 release is simply the current state of cvs as of today, so if more people tried the cvs version and made patches along the way, we'd have less surprises on release day.
I agree with Curt. There are two basic strategies for releasing:
1. Release rarely, testing every release exhaustively first.
2. Release often, testing every release only lightly.
I think that #2 works better for most cases -- many bugs won't show up during testing by the members of the developers' list anyway, so it's best to get the release out into the wild and find the real problems earlier rather than later.
I know that some people like the idea of separate development and stable branches, but unless we're dealing with critical core infrastructure like a kernel or Web server, it's hard to motivate people to spend all the extra time to backport bug fixes and OS compability changes to the stable branch: it often ends up that the development branch is more stable than the so-called stable branch anyway, while making twice as much work for the maintainers.
I would support a 4-week code freeze before 1.0, however, and I do think it's just about time for a 1.0.
All the best,
David
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
