[crossfire] 1.60 release thoughts

Mark Wedel mwedel at sonic.net
Tue Feb 1 00:45:37 CST 2011


  1.60.0 is close to being out the door, it might be by the time you read this 
message - after doing it, I've had various thoughts:

- With SVN tree, all computer generated files get removed - I think the only 
thing really left is some of the macro files - since developers out of SVN are 
going to need autoconf/automake, pretty likely they will have 
aclocal/libtoolize, etc (in fact, I think those later ones are in autoconf or 
automake packages anyways)

- Within the file release on sourceforge, I think it makes more sense to just 
have the version directories at the top (eg, 1.60.0, 1.50.0), and then under 
each one, put all the associated files - server, maps, client, different clines 
(linux, windows, java, etc).  That would certainly be easier to navigate - very 
clear what the latest one is and no hunting for files.  If we do get the case of 
some files not released (lets say we do an interim 1.61.0 for clients but not 
server), the readme there could note to use the 1.60.0 server.  Thoughts?  This 
becomes perhaps more relevant when jxclient and gridarta are added, as then 
there are lots of top level items.

- At some point, the legacy character creation code should get removed, and 
related, basically all the ST_ values/player_set_state().  Anything that should 
have confirmation should be handled on the client, eg, if creating a party, 
should be an interface on the client to do that, which confirms the party 
password (and throws up an error if a mismatch), and it just sends the command 
to the server - maybe a protocol command for that, but there really isn't any 
reason password confirmations should be handled on the server.  This just makes 
a much cleaner design  - if a character is logged in, they are always playing.

- For ChangeLog/CHANGES file:  I suggest the ChangeLog file get generated by 
svn2cl - this is already done for maps.  But each area also has a CHANGES file, 
which updated by hand but is used to note improvements/things of more general 
interest - hard to say where to really draw the line, but reformatting, minor 
bug fixes would not go in the CHANGES file - big features would.  Maybe the 
determination is anything that actually affects gameplay?  Thus, bug fixes 
wouldn't typically get put in (they may change gameplay because someone is 
exploiting a bug).  One reason I bring this up is that with the maps ChangeLog 
file from SVN, really no way to get any real useful content from that - I pretty 
much used the crossfire traffic - it is that type of stuff that could perhaps 
get put in the CHANGES file.




More information about the crossfire mailing list