[crossfire] 2.0 release, was Re: Code restructuring

[Alex Schultz]

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