Yes, adding more versions just adds to the confusion.
Changing the version number once all the bugs are fixed sounds like a good idea.
Also, as we've suggested before, they way these releases are brought out really needs to be changed. I know I've contributed to the problem by making last minute changes to Hooville, but this kind of thing needs to stop. We should set an update deadline for when all updates that are going to be released have to be finished and submitted. This should be well before release time. Probably a week or so. Then if bugs are found, we'll have time to fix the package before a major release. It wouldn't hurt to designate a few trusted gamers to test out the package. People who will keep quiet about any suprises you might like to have included? (Reasonable surprises, like cool new levels).
We NEED a changelog. In fact, we should post the changelog at about the time all updates need to be in. (Maybe a day or two later to allow for documenting last minute changes made before the update deadline). This changelog should be detailed and posted on the forums so people will read it and can have time to discuss it, or launch objections. It wouldn't hurt to post intended changes for the next update well before this submission deadline. Also, a changelog of exactly what ends up getting released should be made available in time for the release (probably with it). This will acount for any differences with the intended version and what gets released, due to perhaps removal of certain items due to bugs.
We should be fairly strict about the deadline. If something isn't ready, it'll have to wait for the next release. We also need some rules about bug fixes. If something was submitted but is buggy, we either need to revert back, or fix the bug. If an attempt is made to fix it, then time must still be available to test the fix. Maybe save the last 3 days before a release for text file changes only (change logs, credits, instructions?, etc.). Any bug fixes will have to be incorporated before this point. If any major bugs are found after this point, the item in question will simply be removed, no fixes allowed. Any fixes will have to wait for a future release for the item to be incorporated.
Of course, no set of rules is perfect. If we need to deviate from whatever rules are set out, a post should be made about it. It shouldn't be carried out by one or two individuals who are responsible for packing up all the changes. We don't really want changes done in secret. Perhaps if a major important update becomes available a day or two after the submissions deadline? It'd have to be an important change, whatever it is, and should obtain a rough concensus. Perhaps a post describing the potential addition to the package, and a few replies approving of the idea? Providing there are no major objections, I guess it could be done.
Well anyways, I'd also like to say that if an update can't be completed by the scheduled release time, it should either be cancelled or rescheduled. It's a pain in the ass to fix things once they're out, or to find and sort through unexpected bugs. (Not just for the programmers, but the players too). When this sort of thing happens, it'll probably lead to decreased interest overall in anything to do with the updates or Outpost2.
Lastly, maybe we need to rethink this strong coupling between released and reunions. They don't *have* to coincide. I can see why they do. It's certainly ideal to have the two go together, but we shouldn't get stuck with the mentality that they're the same thing. If we feel we have to cancel an update/release right before a reunion time, then maybe we should go ahead with the reunion without having an update. People may try to schedule themselves to be free on reunion weekends, so you might not want to cancel that with the update. Also, there are certain things that should be released as they become available and we shouldn't sit and wait for a reunion to release them. Things like the NATfix or map editors should probably be released as they become available. It's probably better if things like that are released before reunions so people can play and practice up, or work on new maps or whatever for the next reunion, or update, or whatever. Of course, it's still a good idea to include things like the NATfix with an update package, but there is nothing wrong with providing that as a seperate download.
