[crossfire] Crossfire+/Crossfire2 Versioning and Metaserver

[Alex Schultz]

Robin Redeker wrote:
> Hi!
>
> Some time ago we heard on the irc channel (some month/weeks ago) that
> some users find the '+' suffix of the crossfire+ servers confusing.
>
> Now that we removed it, it seems to be even more confusing (as far as
> gros or others on the IRC channel are concerned).
>   
Indeed, I would agree that both ways are quite confusing and without the
"+" perhaps moreso.

> So, now the question: What version should we send to the metaserver?
> What would you like most? 'CF+<version>' would be an alternative that would
> distinguish the crossfire+/crossfire2 servers from others.
> We would also be fine with '<version>++', it would also sign nicely that
> our codebase is C++. Or also the old '<version>+' scheme is fine with us.
> ('cf++<version>-perl' would be a bit too cumbersome IMO :-)
>   
Similar to what I talk about a few paragraphs below, '<version>++' I
feel would imply too much that it's a 'successor project' (which it
isn't by my definition) as opposed to a fork. I do agree though that
'cf++<version>-perl' would be cumbersome, however at least it does not
imply incorrect things that appending a "++" would. IMHO there is no
good solution with the version column as is and a single metaserver, and
thus solutions as you mention below or a separate metaserver would be
best in my opinion.
> Maybe in the long run a column that has the header 'Gamebase' or
> 'Codebase' on the metaserver would distinguish server types best.
>   
Given the nature of things lately, it would seem that either a column
for such would be necessary, OR that separate metaservers be used for
separate servers running with each codebase.

Another thought, somewhat off topic from this thread, is it would also
probably be a good idea for the metaserver to contain the "protocol
version" that is in the protocol. This hasn't been used much lately, in
favor of setup flags, however in Crossfire 2.0 we plan to remove
compatibility for really old protocol mechanisms and that would mean it
would be best to remove some 'setup' flags and increment the "protocol
version". In a few discussions on such there's been a consensus that
between major version we'd increment the "protocol version" while within
a given major release number, we'd add setup flags, however this is not
an official decision. Relating back to the topic of this thread, how
will the protocol's builtin "protocol version" number be handled in
light of forks such as "CF+"?

> Also w.r.t. to our project name that we lateley changed to 'Crossfire2':
> What should we name us? What would you like most? We would be fine with
> going back to 'Crossfire+', but we changed it in the first place in
> response to the discussions on #crossfire.
> It would help to have an official position from you.
>   
I feel that Crossfire2 is even worse personally. Firstly that would
imply that it's a 'successor project' as opposed to a fork ("Crossfire+"
was a little bad in terms of that too IMHO, but not as bad as
"Crossfire2"). To me, the naming of the fork implying that it is a
successor project is one of the most annoying (and potentially
confusing) part about it. Secondly, over on this side, we are intending
on having a Crossfire 2.0, this it probably at least a year away from
being released probably, however a fork named Crossfire2 would be
extremely confusing once Crossfire 2.0 is released.
Note, this is not an official position as I am one member of the
project, however  "Crossfire2" vs. "Crossfire 2.0" confusion is
certainly an issue, and I have a feeling that many of us on this side
feel some agitation at how "CF+" tends to present itself as if it was a
'successor project' as opposed to a fork.
(Quick note: I define a true "successor project" as a project that is an
official successor where the original is generally dead and the
developers have moved over.)


Alex Schultz