Mark Wedel wrote: > One thought is to define major.minor.micro releases like this: > > major release: Changes that break compatiblity (need to start with a clean > server as player files are not compatible, server/client compatibility may be > an > issue, and/or programs removed (x11 client goes away for example). > I feel that changes that break compatibility should not be required in order for there to be a major version change, I believe that a major change from the gameplay point of view, would also go to major releases. Also, variability of automated conversion utilities should not disqualify map/arch/playerfile/etc. format changes from going towards a major release. Essentially, what I think should be put into major releases instead of minor, are things that are either, large projects in addition to things that break things. > minor release: feature enhancements and bug fixes. > micro release: only bug fixes. > These definitions work for me, though as noted above, some non-breaking feature enhancements should go to major instead if they truly are a large change (i.e. major code restructuring for example, or things very major from player perspective, should be saved for major releases) > In terms of CVS, that could work out like: > > head branch: Contains major release - all changes (unless not applicable due > to > other changes) go in the head. > > stable branch: This is where minor/micro releases come from. When a new > major > release is done, a new stable (stable-2-0-0, stable-3-0-0) is done. I really > only see one stable branch per major release - the determination of > micro/minor > is a call of the RE at time of release based on what changes. I think in > this > model, releases done on a fairly regular schedule (quarterly? Every 6 > months) > since the number of changes probably won't be that big. > This makes sense, except for one thing. Unless we set up hard cycles of development, or make micro releases for even fixes of things as small as two non-critical bugs, we will have almost no micro releases ever, because every time time there are enough bugfixes to be worth making a micro release, we most likely would also have a couple feature enhancements which would force it to be a minor release instead of micro. One option if we want micro releases to be meaningful, is on a frequent regular basis, check if there are a couple or more bugs that were fixed in the cvs stable branch, and if there were no feature enhancements in that same timeframe, then make a micro release. > The question is then who is responsible for updating the stable branch. IS > the developer who commits the change responsible? Do we have some people > responsible for maintaining the stable branch and they make the call on what > changes to pull out of the main? And you get that thorny issue - what level > of > enhancements from the main branch get put into the stable branch. While some > may be obviously incompatible, there could be other ones which are pretty > significant changes. > Well, I think that we don't have the manpower to maintain a stable branch separately like some larger projects may be able do, hence I think it should be the responsibility of the developer who commits. One other note you didn't really say anything about, is once a major release is released, the only stable branch that should be maintained should be the one for that major release number. What I mean is, when 3.0.0 is released, we should no longer bother with the 2.x.x branch, and the stable branch for 3.x.x will be made, and then the head branch will represent things for 4.0.0. > Under this model, I don't think you want to go too long between making > major > releases - simply because as more time passes, the code from major and stable > will drift farther and farther apart, making it harder and harder to take any > fixes from the main branch to the stable branch - this then basically amounts > to > having two different programs to maintain (and/or the stable branch stops > getting change as if I fix a bug in the head branch and can't easily see in > the > code where that belongs in the stable branch, I may not be inclined to get > the > stable branch, compile, spend the time to debug, etc to try and fix that > problem). > Agreed. For that reason, I also believe that a major code restructure should be done in a major release, and the major release should happen immediately after the restructure is done in order to minimize headaches. > That may work if there are people running these CVS servers and clients. > But > the danger there is it can be hard to run a CVS server when a commit at any > time > could result in the entire server being reset - I think you almost need to > set > up various snapshots where you can say 'the code will be stable enough for at > least some number of months' so people can feel somewhat comfortable playing > on > the server, etc. > Well, several things. For one, more frequent releases would make people less inclined to run CVS servers and clients as opposed to releases. Also, not all major releases need to break compatibility and when compatibility, it should be strongly recommended that developers make conversion utilities if it is practical for map/playerfile compatibility breaks. As it stands now, there is just as much danger running a CVS server, except that nobody makes compatibility breaks even when there may be a good reason, hence I think so long as conversion utilities are made and the protocol stays reasonably stable, it should be just fine. > I think then also some form of filtering or a separate metaserver is needed > so > players do play on the appropriate server. Well, I think the best way to do that, would be having servers sent the protocol version that they send in the protocol already, do the metaserver, and we can have clients check against their own protocol version number. In theory that should be very simple to do just so long as people remember to increment that if they need to break protocol compatibility.
Alex Schultz _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
