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