[crossfire] Protocol version

[Mark Wedel]

Nicolas Weeger wrote:
>>   My personal thought is that the trunk gets bumped to 2000.  All
>> additional changes in protocol between now and 2.0 release (or near by)
>> result in changing of the protocol version, and having the client/server
>> both require they have the same version (note that clients are of course
>> free to lie about what version they support, so 1.x clients could claim to
>> be 2000).
> 
> 
> Well, to have "nice" things, what about: we set protocol version to 1900 for 
> now, and when we release 2.0 we fix to 2000.
> This gives us 100 revisions to fix things (including setup commands), which 
> should be reaaaaaaaaaaally enough.
> IMO having 2.0 <=> 2000 is simple to check, and is symbolically strong :)

  Yes - that is fine.

> 
> Of course, after 2.0 release, we'll go back to small increments when needed, 
> or setup commands.

  Right - setup works fine for minor changes - and in fact is what has been used 
for quite a while instead of changing the protocol versions.  It is just nice, 
on both client and server side, if changes can be made to the protocol without 
having to worry about setup commands, if version is not this, do this, else that 
type of logic.

> 
> 
> Agreed on the rest, but I'd keep the framework for those additional things 
> (eg: I kept "mapmode" even if it is always map2cmd, so that when we need it 
> again, well, it's there).

  right - setup is nice, and still useful for config things.  What can go away 
are all the standard things - eg, a 2.0 client is going to use map2, item.., 
ncom, etc, so there is no need for it to negotiate that as part of the setup logic.

> 
>