[crossfire] Client Snapshot Builds

[Mark Wedel]

  Quick notes (I've probably missed some - if I've missed anything important, 
follow up).

The list of supported platform is largely based on user input.  I've not had a 
mac, so that is based on someone providing patches (if necessary) and saying it 
works.  On going testing of those platforms does not happen by me, and maybe not 
at all.  At one point, I think the list was a lot longer, but then we started 
asking 'just when is the last time someone tried to compile on irix?'.

  For what its worth, I've moved for redhat linux to solaris (x86/amd64) so 
cover that base.

  The official release cycle is slow for a variety of reasons - off the top of 
my head:

- Broken release system - the tools/components are there, but changes have been 
made (addition/removal of file being most common) such that release/packaging 
fails.  Not hard to fix, but takes time.
- For official releases, desire to have stable components (no big check in the 
day before).  But folks also like to have a chance to fix bug and make other 
changes before the release, which sort of goes against stability (fixing bugs 
should make things more stable, but not always the case)
- Scheduling becomes a problem - between the packaging, uploading, and updating 
the page on sourceforge, it would be a couple hour process.  It may be the case 
that I have the time right now, but to let everyone have a chance to put in the 
patches, change, etc it means a couple weeks time, when I may not have time.
- The only real part of the official release was the source tar balls.  Binaries 
may come later or not at all (I only did x86_64 rpms - never did anything more)

  On those notes, things to make releases happen more often:
- Folks other than me doing releases.
- Use standard release train model (release happens at this time - if change 
isn't done, need to wait for next train/release).
- More frequent releases such that missing a train isn't as big an issue.
- Do more frequent in between snapshots - if this uses same logic/scripts as 
official releases, it means that problems related to missing files get found sooner.

  A lot of that is easier said than done.  I've also said that I'll try to do 
releases more often, but finding time to do so is often hard.  And even on 
second point of release train model, I suspect that dates would be vague or in a 
range (something along the lines of 'Release schedule will be January, May and 
September').  That gives entire month to find the necessary time for a release, 
and not a specific day.

  One last note - with various free VM solutions out there, it now does make it 
easier to releases for multiple OS's or doing 32 bit releases on 64 bit linux (I 
know of the problem Lauwenmark speaks related to trying to do a 32 bit release 
on 64 bit linux - solution would be to have a 32 version installed in a VM)

  Now in terms of the 2.x branch:

For the client, given that lots of good stuff has gone into the 2.x branch and 
nothing really removed that breaks compatibility, I'd be tempted to take what is 
currently 2.x and make it the main trunk (I'd need to think about it more and 
see what changes have been done).  To prevent confusion, a long time back it was 
decided that the client would mirror server version - that normally worked 
pretty good when we were just doing incremental 1.x release, but doesn't work as 
good for 2.x.

  The reason for tying the versions together is it made support easier - just 
tell users to make sure their client was at least same version as server and 
things would work.  But also since that time, the protocol has stabilized a 
great deal.

  Now the idea of the 2.x client (and thus server) was that at time of release 
of 2.0, the client would fully support the 2.0 protocol and nothing more (all 
code related to deprecated commands would be removed.  All setup or other option 
related to protocol control would also be removed, such that at startup, the two 
  would already be speaking the same language.  Some setup commands related more 
to control/preferences would still be in place).  Such a client almost certainly 
would not run on a 1.x server, and a 1.x client would not work with a 2.x server.

  But that hasn't happened yet, and the current trunk client certainly does work 
on the 1.x servers, so maybe it does make sense to take what is in trunk and 
call it 1.x - it would get more folks using the features that are there.  It may 
just make sense to just work on trunk until such time when it really does become 
incompatible with 1.x clients.

  For the server, this is a trickier question - the trunk server clearly is not 
ready for official release - sure it will run, but work on balance and other 
areas need to be done.  One has to ask what do we get by releasing it more 
widely - I think we'd certainly get a fair number of bugs or questions related 
to known issues.  I'd be more tempted to do snapshot releases after certain 
major things are done but before the next one is started.  And those release 
would still have to be marked as alpha/experimental.  But maybe it doesn't even 
make sense then - if folks really want to play with it, having them know how to 
compile and get it from SVN may be a first level sanity check.  The number of 
folks that download the server as is isn't that huge, and for pre-release test 
versions, I think it'd be even lower.