[crossfire] 2.0 release, was Re: Code restructuring

[Mark Wedel]

Alex Schultz wrote:
> Mark Wedel wrote:
>> 1) What is the target date for a 2.0 release?  It can't be 'when all the cool 
>> stuff is done', as then it never happens - always something new to add, etc - 
>> some general date has to targeted.  I had previously mentioned shooting for end 
>> of this calendar year.
>>   
> Well, I think that targeting a general date may not be the best
> solution, and a better one would be having a feature-based target.
> Essentially based upon the sort of things you talk about below. We just
> need to limit the number of "must have" things to be reasonable and wait
> till we have those, and a few "nice to have" things.

  Have to be careful and limit the feature so that you don't keep adding more 
things to be done, to the point where nothing ever gets done.  Whatever is 
targeted for 2.0, there will be things that should be done for 3.0, 4.0, etc. 
The next version can't hope to cover everything that should be done.



> Another issue though, is due to the way that crossfire has released in
> the past, releases with minor version number increments are a mixture of
> bugfixes, minor features, and major features. One question is, what will
> make the difference between 1.9 and 2.0 so different from 1.7 and 1.8?
> Really, I don't see how anything that has happened or is planned for
> 2.0, will really make the change so much bigger than the difference
> between 1.7 and 1.8. For an even better example, the difference between
> the releases where the skills system changed a bunch, is probably much
> more worthy of a major version change, than what is currently planned
> for 2.0 IMHO. Personally, the only way I can see things changing enough
> in a single release to in my opinion warrant a 2.0, is if we start
> keeping a "stable" branch in CVS and have that used for minor releases,
> or if something either in code and/or gameplay undergoes a major (in a
> loose sense) restructure.

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

minor release: feature enhancements and bug fixes.
micro release: only bug fixes.

  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.

  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.

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

  IMO, this CVS/release model actually is pretty good.  The problem is how to 
handle the head/main CVS branch.  It would seem that official releases are never 
made from it until the target for what constitutes the release is made.

  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.

  I think then also some form of filtering or a separate metaserver is needed so 
players do play on the appropriate server.