Alex Schultz wrote: > 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.
I didn't mean to imply that is the only justification for a major release. Just if such a change is made, no matter how minor otherwise, that should warrant an increase in the major release numbering. > Also, variability of automated conversion utilities should not > disqualify map/arch/playerfile/etc. format changes from going towards a > major release. But those can't always work and/or creates other problems. In the past there have been changes that change things in various ways that would be hard to automate, and/or would make changes to characters that would be unexpected to players (try to explain to players why their stats are different now than last night, or why their item isn't as powerful) - you'll get a lot of upset players in such cases if a player who used to have no problem killing monster X is now killed by it because of changes made to the character. There is also the issue of fairness (character X created before change is made and is thus more powerful than new character Y can be under revised rules). And there is some cost in time, testing, resources of writing such conversion tools. At some level, you just have to say 'hey, the game has changed, start over'. We just have to be careful that doesn't happen too often. >> 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. If there are never any micro releases, that is fine IMO. In fact, I'd generally not expect there to be many micro releases, but I could see see a minor release made, a critical bug found a few days later, and can't really justify a minor release, but you need to get a new version out, so do a micro. >> 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. Yes - I didn't say that in terms of major/stable, but that is how I expect it. It may be reasonable that right after a major release, the stable branch for the previous gets updated for some limited time - sort of same above - if 3.0.0 is released, and the next day, a major bug is discovered that affects the 2.0.0 stable branch, may want to still update that 2.0.0 stable and make a release simply because it may be unreasonable for everyone to switch over to the next major release in a few days (I'd say this overlap time would be 1 month at most, but then this also sort of depends on how often major releases are done - if major releases are done every 6 months, then updating to major releases shouldn't be seen as such a big deal). >> 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. But that can then lead to rapid turnover of major releases. Eg, I do major code restructure, make 3.0.0 release. Then some other change is made (maybe compatibility breakage, maybe some other code restructure) - do you make a 4.0.0 release 3 months later then? I think there needs to be some minimum/maximum gap between major releases. > 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. but IMO, allowing breakage is one of the advantages of major cycles. There is lots of old code related to protocol handling to support old clients. That should get pulled, but may break some number of clients. And conversion routines, as mentioned above, can still be problematic. Now there is no technical reason multiple servers can't be run on the same physical box (don't even need virtual hosts, but that could be one of the easier ways - another would be to use different port numbers) - that could help server admins - they could set up the new server on some new port, and use different set of player files, etc. but I think it is desirable to periodically start with a clean slate. While conversion scripts are nice, if the changes are significant, we shouldn't be afraid to force a restart. We should limit how often we do this (and/or try to consolidate as many of those changes into one major release vs stringing it out accross several major releases). _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
