The way I'd do 2.3 releases is: 0. Make Fastdeath's server build daily SVN snapshot builds, so hopefully the changes in current SVN get a bit more exposure before being in a RC.
1. Branch a release branch off from 2.3 (either abusing a tag, or making a separate branch and tag from that), branches/2.3.6 for example. 2. Prepare the first RC and release that. If using branches/xxx, the tag is only a copy of the current branch without further changes. 3. Commits go to 2.3, and only those fixing problems discovered in the rc are backported. 4. Goto 2. until no new problems appear and the last rc becomes the release. That allows normal commits into 2.3 as usual, without delaying them until after the release. It also means fixes need to go into two (or three, including trunk) branches, but that should serve as an incentive to keep the rc cycle short :P. As for going to 2.4, I currently don't see much reason for it. We're doing more than pure bugfix releases, but not enough new features to justify the higher number imo (or we do that for every release...), so I prefer staying with 2.3.x for now. Or does anyone have features planned that "need" a new version? _______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
