On Sunday, 12 September 2010 at 22:24, buginator wrote: > 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.
So how long would this bugfix 2.3 live? Until 2.5 is done, and then 2.4 is fixes only? By what criteria will the jump to 2.5 happen? How about doing 2.3.5.x releases for bugfixes only instead? So for example we (finally) branch 2.3.5 now (and immediately push CorvusCorax's projectile fixes in 2.3 for 2.3.6), tag (hopefully no more) RCs from it, the release, and the 2.3.5.x fixes. I realise that half of it is just naming, but the other thing is that we currently use .warzone2100-2.3 as config folder, and I don't think most planned additions will break something in it (and I don't think reusing the 2.3 folder for 2.4 is a good idea). I think my proposal should work out about the same as yours, just with less disturbance both for users and in SVN. (Well, and there's the question of how well the bugfix only thing will work out, I remember both the 2.2 and 2.3 jumps, and though both times there was some interest in keeping the old line alive in parallel for a while, in the end only the new version was released.) _______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
