[crossfire] 2.0 release, was Re: Code restructuring

[Alex Schultz]

Mark Wedel wrote:
> 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.
>   
Agreed.
>> 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.
>   
Yes, agreed. Not all breakage can be dealt with by conversion scripts in
a "proper" manner, however my point was that where conversion IS
possible in a safe and "proper" manner we should make converters.
(Things like, splitting of multi-meanings for attributes, comes to mind,
with regards to converting map data).
>>>   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.
>   
I thought you would expect it as such but thought I would bring it up. :-)
>   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).
>   
That makes sense if there is a demand of it, but I'm not sure if there
is, or even if there isn't much of a demand, makes sense for more
critical bugs shortly after a release anyways.
>>>   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.
>   
This is true, however I can't see major code restructures working well
as part of a minor release. What I see as ideal though, is if the trunk
gets a few major features almost worthy of a major release, then a code
restructure happens, and a release happens afterwards. Of course, timing
may not work out so ideally, but perhaps it might be good for people to
try to time their major code restructures to finish about just before
when a major release is anticipated.
>> 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.
>   
Yes, this is true, however despite that, not all major releases need
break things, and no sense breaking things unless there is a logical
reason to.
(random thought about old clients: There are a good number of people who
still use the plain X client, the gnome client though, I don't think is
in usage though I may be mistaken)
>   And conversion routines, as mentioned above, can still be problematic.
>   
Conversion routines as I noted above are not a catch-all, but are
something that should be done where reasonable, safe, and "proper". For
one, in the case of changes in map file format, conversion scripts
should typically make sense. However if the breaks are due to behavior
changes, it usually wouldn't make sense to do a conversion script.

Alex Schultz