David Megginson said: > Curtis L. Olson wrote: > > > 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.
At one time I think I would have leaned toward #1 but have since become a #2 fan. I was going to say this yesterday, but I also realize that doing #2 often involves quite a time commitment. Would it make sense to run a nightly script for folks that don't run cvs? Or is that just a waste of bandwidth? Maybe binaries are the ticket. How about various team members running nightly build scripts and then uploading the results somewhere? > 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. That's right. Maybe some day simgear, but I would think that backporting efforts would be driven by the requirements of the backporters rather than anticipated as a requirement. > 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. > We're close, maybe next release, but I think we need to get the subsystem/initialization thing straightened out first. Fred's fix for the tilemanager last week raised an issue about something that might be missing in the subsystem design. Best, Jim _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
