[crossfire] 2.0 release, was Re: Code restructuring

[Mark Wedel]

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).