On 9/12/10, Christian Ohm wrote: > 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?
Our repo doesn't behave like a normal repo anymore, where 'trunk' is used for testing, and then branch from that for the next release. I was going to change GAMESTRUCT to add more requested enhancements, and that will require a masterserver change... However, that doesn't really mean we need a new major version for that. It is just that I was thinking that 2.3.x will only get bug fixes only (from now on), and all new features will go into a new 'base' branch that we can use like a trunk, and then have snapshots (weekly or as needed) out for testing. I know this was tried before, and things (features) kept slipping in, but the way things are working out isn't really maintainable. I rather not have multiple fixes that fix fixes since it was a new feature, and not strictly a bug fix for a 'stable' branch. _______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
