[crossfire] Crossfire+/Crossfire2 Versioning and Metaserver

[mwedel at sonic.net]

> On Sat, Apr 14, 2007 at 01:20:40PM +0200, Yann Chachkoff wrote:

> Not only parts, the whole C code has been made compileable with g++.
> But to the _user_ there isn't a big change. I mean, if the current
> crossfire server is rewritten in for example scheme and speaks the same
> protocol and has the same or similar rules, would it be crossfire?

 No - that would be some other server/program.

 It could certainly be called 'crossfire compatible' or the like, but
claiming it is crossfire would be false.

 This is true for any program - if I rewrote the 'cat' program completely
from scratch, I really shouldn't call it cat.  I could call it mcat
(marks cat), or ncat (new cat), or whatever, but I'd be loathe to call it
new cat, as that doesn't say a whole lot about the name.

 A better real life example may be emacs - there are forks or derivative
programs, but they do have a different naming scheme - xemacs, emacs,
etc.  They change the name in some regard - xemacs doesn't call itself
emacs10, they did make some noticable change - more than adding a number
which is easy to confuse with a version, or a + which is somewhat
misleading.  They don't have a name that in any way suggests it is the
successor of suprerior, but rather have a name that suggests it is
different.

 So I guess call it scrossfire (schmorps crossfire) may be reasonable, as
that is a different name.  But calling different programs that same
logical name even though they share no code base is wrong IMO.

>
> The project is indeed different, but why shouldn't it have 'crossfire'
> somewhere in it's name when it's inheritance is still so much visible?
> (Daimonin has indeed nearly nothing to do with Crossfire anymore, but
> thats mostly because they use completly different rules, graphics and
> overall design).

 Note however that when they forked off, they switched the name
immediately, when they were still basically crossfire.  AS time passed,
things drifted apart.

 A valid question of course is whether that version will always remain
compatible.  Saying yes implies that any and all protocol changes we make
will also be done in your server also - can you say 100% that you are
going to do that?


> Could you re-read my question? I'm not asking about 'Crossfire2', I was
> asking about the confusion that is created when we have 'Crossfire' in
> our name. Eg. 'Crossfire+' or 'Blabla-Crossfire-BlubbBlubb'.

 It depends on how you form your name.  After typing above, I'd say that
having crossfire in your name is OK, but it should be named such that it
does not create confusion suggesting it is the successor or latest
version of crossfire.  Both crossfire+ and crossfire2 suggest those
things.

 Likewise, crossfire-extended was another such name.  So I wouldn't mind
it being called scrossfire, or rcrossfire, as that more clear suggest it
is different in some regard.  ncrossfire (new crossfire) I would not
like, as once again it suggests it is a replacement to crossfire, which
IMO is patently false, since crossfire is still being developed.


>
> I agree that 'Crossfire2' is propably a bit confusing when it is
> mixed on sites like freshmeat or linux game tome. But at least as far
> as I see it: a name like 'Crossfire+' or 'Crossfire-ng' is pretty
> different from 'Crossfire' and shouldn't cause confusion.
> Similar as 'syslogng' isn't confused with 'syslog' or 'quake' with
> 'quake2'.

 crossfire+ is, as that is just like crossfire2 - suggests it is a later
version.

 Crossfire-ng is probably ok, depending on what the ng stands for.

 The quake analogy is I think false, given the people who wrote quake
wrote quake, and/or those people had no intention of doing a quak2
themselves.

 In fact, I'd say it is reasonable that at some point, we may in fact be
releasing packages called crossfire2 - I don't think we would change the
project name, but perhaps the packages.

>
> In the jabber community there is jabberd14 and jabberd2. First jabberd2
> was meant as successor of jabberd14, but jabberd14 couldn't be replaced
> by jabberd2 and it still persists and is developed. And there is only
> few confusion about the differences of both as they are distinguished by
> the '2' and '14' in the _name_ part of the project. jabberd14 has the
> version 1.6.x now.
> It seemed indeed to have seeded some confusion, so the placed a note on
> the website of jabber14 that jabberd2 is a different project. But at
> least to me they are very distinct.

 I don't know the details about jabberd2, but I better know gtk+, which
has both gtk+2 and gtk+1, since like you describe in jabberd, there was
some need to still use/support the old version even though there was a
new version.

 A major difference in that case vs yours is that for gtk+2, it is the
same people that did gtk+, and thus that naming was done with their
permission (and probably same developers), same web site, etc.  And in
the case of gtk+, while I think a lot was rewritten, it certainly shared
some common code.

 My main complaint with calling yours crossfire2 or crossfire+ is that
both of those suggest it is a successor to the crossfire project, which
it isn't.  It is really (at least from what I gather) a parallel project
that is crossfire compatible.

 If I (as the official maintainer for crossfire) and the bulk of the
developers stopped doing work on crossfire, I'd have less complaint about
someone else taking up the torch and calling their project crossfire2,
crossfire3, whatever, but that isn't the case.  Crossfire is still quite
alive an kicking, and anything that suggests it is the successor is
misleading.  There are probably good reasons to use it, just like there
are reasons to use syslog-ng instead of syslog, but there is a difference
between that and choosing a name which suggests you have the latest
version.

>
> We don't object to change the project name to 'Crossfire+' again. But
> some rationale or explanation why that still is confusing would be nice.

 crossfire+ - suggests later version of crossfire.  Eg, if I see
crossfire+-1.10.0, I'd think 'hey, that is a crossfire server running
1.10 with some extra patches/content'.  I wouldn't think 'that is a
completely different codebase'.

 I've already stated crossfire2 naming.

 As said above, having the name crossfire in yours is probably OK, if its
naming is somehow done to suggest a difference.  But to come up with a
detailed list of what is or is not OK is difficult - probably easier for
you to provide a few names and see what people think.

 On the flip side of this, you can look at another project/protocol -
httpd.  There are lots of httpd servers out there, but they have
different names (apache, java web server, whatever else).  They don't all
have httpd in their name - they rely on people to know that they are a
web server.  So from that basis, there isn't a requirement that a program
have crossfire in its name just because it is crossfire compatible.