Re: [crossfire] 2.0 release, was Re: Code restructuring
Alex Schultz wrote: Andrew Fuchs wrote: Finally, i just want to note that our next release could be 1.10.0 instead of 2.0 if we need more time for cf2.0. And that is something I strongly believe should be the case. I personally do not believe that we are ready for 2.0 for a while (I'm thinking about 6 months or so if not a little more), and I believe in the meantime that we should do at least one release such as 1.10.0. However I believe the point of another release between 2.0 and now to gain more time, is fairly moot unless people can work on 2.0 in cvs starting fairly soon, hence, I believe that the best solution would be to create create a new cvs branch for working on 1.10.0, and then work on 2.0 things in the main branch. In terms of debate between making a branch for each major version, or each minor version, I personally don't have much preference on, but I feel that a branch of some sort is needed. Also, I believe the type of code restructure I mentioned a little earlier on the mailing list, should be something to target for 2.0, though I personally wait about a month to start work on it to allow people to get used to usage of the branches and possibly to apply pending patches that have been lying around for a while already. Yes - a stable-1-x branch is needed. One question not directly addressed on all of this are the different cvs trees. server: pretty clear on major/stable branching client: probably same thing (should the model be followed with client release matching server release number? arch: Does this model make sense? I suppose in some sense because as changes are made, that may enable or change behaviour of archetypes. What about new archetypes that are release independent? maps: Basically same question applies are for arch. However, maps could be more a problem because patching/fixing maps could become very tedious. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
Mark Wedel wrote: Right - I don't think anyone right now is arguably against having the head be bleeding edge and aimed for the next major release and another (or multiple) stable branches. Agreed. The question is what goes into the stable branch. By its nature, everything has to go into the head branch (presuming the change is still applicable). But the scope of changes for the minor releases in the stable branch probably shouldn't be too big. Personally, I think things to go into the stable branch, are of course things we want in minor releases, and in my opinion, that should be bugfixes, and features that are not large/extensive. Of course, then the difficulty is in defining how large or extensive makes it worth putting in for the next major release, and that I believe needs to be decided in a case-by-case basis. I think also it may be best if all the major features go through design discussions even if there isn't anyone that is necessarily going to work on them. I know that for me personally, there are times when I am unexpectedly ready to do some coding. However, if it is going to take 2 weeks to get input from a design document I write tonight, then 2 weeks from I may not have the time or inclination. So there needs to be something that people can just pick up when ready. Many discussions on the mailing list are already ones where there isn't necessarily anyone going to work on them :P 2.0 release. branch for 2.1 is made based on 2.0 2.1 is released, branch for 2.2 made based on current head code 2.2 is released, branch for 2.3 made based on current head code If that is the model, then that really isn't any different than what we do right now, which means by the time 3.0 is really released, it won't look that much different than the last previous minor release, since the code for that previous minor released was based on code pretty close to the 3.0 release code. Personally I would rather dislike that setup, though I don't believe that is what he is trying to say. What I think he is trying to say is more like: 2.0 release. branch for 2.1 is made based on 2.0 2.1 is release, branch for 2.2 made based on 2.1 2.2 is release, branch for 2.3 made based on 2.2 That said, I don't see how that would end up much different from just a branch for each major release, unless we plan on providing bugfix releases for older releases, which I personally don't see a need to do. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Server setup an Debian - newbie
On Sat, 22 Jul 2006, Penbrock wrote: Good morning all. I have installed the server from the Debian apt-get and it installed fine, or so I thought. It seems that the .deb package does not install the plugins. Where can I find the doc's for an old fart just learning Linux to get the plugins compiled? Hi Penbrock, I'm a Debian user/admin from way back. Debian is known for stability and robustness but not for having the latest packages. The Crossfire server in Debian is way behind the current stable release. As much as I think Debian rocks I've never used the Crossfire server built into Debian. I always compile from source. I think the Crossfire package in Debian would be fine for someone seeing if they like the game but once you get into it I highly recommend building from the latest stable source tree. Cheers, Rob -- Robert Brockway B.Sc.Phone: +1-905-821-2327 Senior Technical Consultant Urgent Support: +1-416-669-3073 OpenTrend Solutions Ltd Email: [EMAIL PROTECTED] Web:www.opentrend.net We are open 24x365 for technical support. Call us in a crisis. If you are emailing regarding an open ticket please consider mentioning the ticket ID as this will assist us in responding as quickly as possible. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Server setup an Debian - newbie
I'm a Debian user/admin from way back. Debian is known for stability and robustness but not for having the latest packages. The Crossfire server in Debian is way behind the current stable release. You must be joking, I suppose ? Although Debian Sarge - the stable branch of the Debian distribution - is indeed out of date (which is somewhat logical), Debian testing and unstable both have Crossfire 1.9.1, which is the latest release of it. Answer to the initial question: The lack of plugins in the Debian package of Crossfire is documented as bug #379348, and has been solved by the package manager (just give it a couple of days for the new package to spread and become available in the repositories). Unless you are (1) using Debian Stable or (2) cannot wait a couple days more, you wouldn't need to worry about compiling stuff yourself. In case you really want to compile it yourself anyway, note that building the Python plugin will require the python-dev package to be installed before you use the configure script shipped with the Crossfire sources. To get the sources, you can do an apt-get source crossfire-server, then cd into the directory created and do a ./configure; make; make install. I also suggest first removing the installed Debian package, to avoid clashes between both. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Server setup an Debian - newbie
Robert Brockway wrote: I'm a Debian user/admin from way back. Debian is known for stability and robustness but not for having the latest packages. The Crossfire server in Debian is way behind the current stable release. As much as I think Debian rocks I've never used the Crossfire server built into Debian. I always compile from source. I think the Crossfire package in Debian would be fine for someone seeing if they like the game but once you get into it I highly recommend building from the latest stable source tree. Actually, debian testing currently has the latest crossfire release (though at the second the package is broken due to a mistake by the package maintainer). Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Server setup an Debian - newbie
Yann Chachkoff wrote: You must be joking, I suppose ? Although Debian Sarge - the stable branch of the Debian distribution - is indeed out of date (which is somewhat logical), Debian testing and unstable both have Crossfire 1.9.1, which is the latest release of it. Answer to the initial question: The lack of plugins in the Debian package of Crossfire is documented as bug #379348, and has been solved by the package manager (just give it a couple of days for the new package to spread and become available in the repositories). Unless you are (1) using Debian Stable or (2) cannot wait a couple days more, you wouldn't need to worry about compiling stuff yourself. In case you really want to compile it yourself anyway, note that building the Python plugin will require the python-dev package to be installed before you use the configure script shipped with the Crossfire sources. To get the sources, you can do an apt-get source crossfire-server, then cd into the directory created and do a ./configure; make; make install. I also suggest first removing the installed Debian package, to avoid clashes between both. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire I can wait, I did find the the person who maintains the package when I was asking in the IRC room and he said he would have it fixed. He also told me about sending the reportbug. I was thinking that plugins where extras . I sure am happy to find out that the debian package will install everything. That is why I picked Debian for my first venture in to Linux, it sure makes it easy in add/update programs. I do have one other issue now. I have one player I use just for DM. How ever when I log him off the server crashes every time and I have to go restart it. Is there an easy was to delete that one? I tried to just quit the player but it does not delete it. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Deleting DM players, wasRe: Server setup an Debian - newbie
On 7/23/06, Penbrock [EMAIL PROTECTED] wrote: ... I do have one other issue now. I have one player I use just for DM. How ever when I log him off the server crashes every time and I have to go restart it. Is there an easy was to delete that one? I tried to just quit the player but it does not delete it. This is how I would normaly do it on my machine: Erase the player's name off of the dm list if it is on there (should be somewhere in /etc/crossfire/ or /etc/games/crossfire or something like that). Then delete the player's directory (should be in /var/crossfire/players/ or /var/games/crossfire/players, etc). I have no idea why its crashing, exept possibly some library or something that wasn't installed just like the plugins. Also I want to note that there are some scripts included with the source code that automaticly restart the server after it crashes (along with dumping it's core, and doing a traceback). -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Server setup an Debian - newbie
On Sun, 23 Jul 2006, Alex Schultz wrote: Actually, debian testing currently has the latest crossfire release (though at the second the package is broken due to a mistake by the package maintainer). Hi Alex. I was referring to Debian Stable, which is what I always mean when I say Debian without further qualification. I avoid relying on any pre-production distro, even for getting a games fix. Cheers, Rob -- Robert Brockway B.Sc.Phone: +1-905-821-2327 Senior Technical Consultant Urgent Support: +1-416-669-3073 OpenTrend Solutions Ltd Email: [EMAIL PROTECTED] Web:www.opentrend.net We are open 24x365 for technical support. Call us in a crisis. If you are emailing regarding an open ticket please consider mentioning the ticket ID as this will assist us in responding as quickly as possible. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Server setup an Debian - newbie
On Sun, 23 Jul 2006, Yann Chachkoff wrote: I'm a Debian user/admin from way back. Debian is known for stability and robustness but not for having the latest packages. The Crossfire server in Debian is way behind the current stable release. You must be joking, I suppose ? Although Debian Sarge - the stable branch of the Debian distribution - is indeed out of date (which is somewhat logical), Debian testing and unstable both have Crossfire 1.9.1, which is the latest release of it. No not joking. The fact I mentioned stability and robustness should give a clue I was talking about the Stable branch rather than the Testing or Unstable branch :) It does seem that while I interpret the term Debian to refer to Debian Stable a lot of others do not, so I'll certainly be qualifying this from now on. Rob -- Robert Brockway B.Sc.Phone: +1-905-821-2327 Senior Technical Consultant Urgent Support: +1-416-669-3073 OpenTrend Solutions Ltd Email: [EMAIL PROTECTED] Web:www.opentrend.net We are open 24x365 for technical support. Call us in a crisis. If you are emailing regarding an open ticket please consider mentioning the ticket ID as this will assist us in responding as quickly as possible. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
Alex Schultz wrote: The question is what goes into the stable branch. By its nature, everything has to go into the head branch (presuming the change is still applicable). But the scope of changes for the minor releases in the stable branch probably shouldn't be too big. Personally, I think things to go into the stable branch, are of course things we want in minor releases, and in my opinion, that should be bugfixes, and features that are not large/extensive. Of course, then the difficulty is in defining how large or extensive makes it worth putting in for the next major release, and that I believe needs to be decided in a case-by-case basis. And trying to define what large of extensive may need some clarification. Some of it may just really boil down to what the developer doing the fix in the head wants to do, unless we put requirements that features within some scope must also be in the stable release. For example, I go off and add some new feature to the head branch, but because I'm lazy, don't put it in the stable branch. Thus that feature is only in the head. someone else could port over that change to the stable release if they really want it. However, as I think about, you probably want these features in the stable branch just so they get more use (and thus may find the bugs that can then be fixed in the head branch). But even that can be error prone - I make some minor enhancement which seems like it would be fine for the stable release, but it actually makes use of some new feature not found in the stable release, so that feature then also has to get ported over, etc. This probably isn't an issue, but when we are talking about doing major things to the head release, may not be as uncommon (looking back at the 1.x releases, think about things like the skill/spell redo and key/value lists - there are many minor changes that have been made since that code was committed that requires it). Personally I would rather dislike that setup, though I don't believe that is what he is trying to say. What I think he is trying to say is more like: 2.0 release. branch for 2.1 is made based on 2.0 2.1 is release, branch for 2.2 made based on 2.1 2.2 is release, branch for 2.3 made based on 2.2 That said, I don't see how that would end up much different from just a branch for each major release, unless we plan on providing bugfix releases for older releases, which I personally don't see a need to do. Even if we are providing bug fixes, I think it would still be better to branch the stable release for those micro releases then branch the stable for each minor. The other problem with the above scheme is you start getting crazy version numbers in files, as each time you do a branch, if you commit/change a file, you get a couple more decimals placed. So under that scheme, by the time you get to 2.9, you could have files with versions like '1.9.2.5.2.7.1.12.2.23.1.6.2'. I think it is much better, and much more common practice for branches to be based on the smaller pieces, and the main branch/head to be where most of the changes are being made. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
