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.
_______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
