[crossfire] Crossfire release
It's been quite a while since there has been a crossfire release, so it seems about time for one. So I'm thinking that in a couple weeks time, packing up what is there as a release and putting it up on sourceforge. There are a few reasons for this announcement: - If there is code/changes that are ready for commit, it gives you time to get those committed (a complaint in the past was someone missing the deadline by a few days and has to wait for the next release) - To be aware of this upcoming release, and _not_ to commit large untested changes. Making a release where the code has had little real world testing tends not to be good. - To focus on bug fixes/stability improvements for the next few weeks. Since a couple weeks is vague, I'll just say end of the month. That does not mean the release will happen on March 1, but it could, so just take that as a deadline. Any concerns, questions, issues, let me know. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire release?
On 11/14/10 09:19 PM, Mark Wedel wrote: Been a little more than 6 months since last official release, and I was thinking that trying to get one out before end of the year might be nice. Thoughts/comments? Any list of bugs or other things that must be fixed before a release is made? Likewise, any list of the major changes since last release? Looking at changelog can be a little problematic, as it may not be readily apparent from the notes whether it is a significant/meaningful change. I figure release should probably be called 1.51, but could do 1.60 - not sure if that makes much difference. Got a bit sidetracked on this, but still thinking about getting it out - maybe in the next week or two. In short summary of the things to do or related notes: call release 1.60 gtk2 client: Change default layout to something else (what?) Changelog: Keep summary short verify 1.50/1.60 client/server interoperability have windows client (who to make?) remove metaserver1 support (very easy to turn it off, but only 2 servers are using metaserver2 right now, despite at least 4 supporting it) ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire release?
Client too old may be reasonable - at some point, the older clients really will not work. It isn't feasible of course to test every client with every version of the server, and vice versa. The problem of enforcing versions gets tricky - one does not want to force version 1.60 client with 1.60 release, as everyone with older clients now have to update right then to play. But I will verify that 1.50 client works properly, and if you are playing older than that, probably time to update. Seems fine to me. Note there was a character creation bug that prevented creating new characters with some versions... Is that suggesting that maybe the java client should be the official windows client. Is that a question? :) No, I'm not suggesting anything. But I admit to not having much interest in trying to build the GTK client under Windows. I haven't looked, so I don't know how easy/hard it would be to take the glade file and make the static config file (old method) - while less than ideal, if there are issues with windows, that may be one approach. Or find a decent libglade version, I think there exists builds for it. Should perhaps metaserver1 support also get removed from server at same time? In that way, the client at least has to be know enough to support metaserver2 to play on newer servers (probably not much difference there, since that support has been there a while). Sure. Let's clean old code. Discussion of that probably gets beyond this message - but some of that also goes into gameplay and other aspects - I certainly think it would be good to have the recipe chains for alchemy be such that one could, through alchemy, reasonably get high experience (this would involve making the basic recipes much more easy to find or perhaps common knowledge (eg, each time you gain a level in alchemy, you learn a recipe for that level). The hard part IMO for quest chains/skill leveling is ideally, you want the process of completely the quest to use the skill in question - having an alchemy type quest which is to get the liver of the boss monster at a bottom of a dungeon is fine, but one really isn't using alchemy (most likely) to solve that quest. A few of those may be reasonable, but I just get the feeling that if too many are about, it might start to feel somewhat artificial. Or have a quest in which you need to create via alchemy some specific item, requiring you to have a minimum alchemy level. Item that can't be traded, or just don't care if a player gets it from someone else. Yes, but I'd almost be tempted that if redoing/adding a lot of graphics get looked at, having an larger image set (64x64 base lets say) would be nice, but that probably gets into the dreamworld below. I'd suggest either some vector-based solution, or why not 3D models - at 64x64 for base tiles, I hope you can start to do nice things :) I suspect that within maps which do set item power, it hasn't been done consistently accross the board - mapmaker A's maps are consistent, but mapmaker B may use a higher basic item power than A. Yup. So a whole revision of that is in order. As well as for artifacts. Nicolas -- Mon p'tit coin du web - http://nicolas.weeger.org signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire release?
On 11/22/10 10:19 AM, Nicolas Weeger wrote: Client too old may be reasonable - at some point, the older clients really will not work. It isn't feasible of course to test every client with every version of the server, and vice versa. The problem of enforcing versions gets tricky - one does not want to force version 1.60 client with 1.60 release, as everyone with older clients now have to update right then to play. But I will verify that 1.50 client works properly, and if you are playing older than that, probably time to update. Seems fine to me. Note there was a character creation bug that prevented creating new characters with some versions... I thought I had checked that, but apparently I missed it. Is that suggesting that maybe the java client should be the official windows client. Is that a question? :) No, I'm not suggesting anything. But I admit to not having much interest in trying to build the GTK client under Windows. My take is that not many of the crossfire devs are particularly active developers on windows, which is why the glade/gtk issue persist. Java (in theory) is very cross platform, so can make for easy client for windows, mac osx, or anything else that can run java. A java client release (meaning posted to the sourceforge crossfire site) should probably be done to make it more known. Discussion of that probably gets beyond this message - but some of that also goes into gameplay and other aspects - I certainly think it would be good to have the recipe chains for alchemy be such that one could, through alchemy, reasonably get high experience (this would involve making the basic recipes much more easy to find or perhaps common knowledge (eg, each time you gain a level in alchemy, you learn a recipe for that level). The hard part IMO for quest chains/skill leveling is ideally, you want the process of completely the quest to use the skill in question - having an alchemy type quest which is to get the liver of the boss monster at a bottom of a dungeon is fine, but one really isn't using alchemy (most likely) to solve that quest. A few of those may be reasonable, but I just get the feeling that if too many are about, it might start to feel somewhat artificial. Or have a quest in which you need to create via alchemy some specific item, requiring you to have a minimum alchemy level. Item that can't be traded, or just don't care if a player gets it from someone else. Or even quests/maps in which various materials are available (in chests, monster drops, etc) which allows one to use alchemy to make potions, bombs, etc to defeat some monsters - at least in that case, alchemy can be used to complete the quest. A character could use other skills (and not use alchemy at all), but at least alchemy could be used heavily, so it makes more sense to get alchemy experience. It would perhaps also be interesting that if one makes a device through alchemy (dust as an example) and uses that dust to kill creatures, may some portion of that experience should go to alchemy. Not sure how to do it all, and it probably has to be limited to the character that created the dust also using it. But in a sense, you are putting your skill to the ultimate test there. Yes, but I'd almost be tempted that if redoing/adding a lot of graphics get looked at, having an larger image set (64x64 base lets say) would be nice, but that probably gets into the dreamworld below. I'd suggest either some vector-based solution, or why not 3D models - at 64x64 for base tiles, I hope you can start to do nice things :) From having done this a few times (bitmap to xpm conversion, 24x24 to 32x32 conversion), being able to populate the entire new image set is a big plus - in this case, that would mean having all images available as 64x64 images, even though they are just scaled up 32x32 images. Now at that point, how to clean those up is another question - for some number of images, probably just doing manual cleanup is fine. For some, it may be making a 3d model or other basis, and then doing manipulations on that and saving in 64x64 image may be best. For something like some characters and monsters, making the 3d model which you can then rotate for the 8 different directions as well as do basic animation (moving arms/legs) may be a lot easier than actually drawing all those images by hand (but not having done much with 3d models, can't really say myself) For others, doing vector graphics and saving/converting those to 64x64 png images may make sense (for non animated objects that also wouldn't have any rotation, this may make sense - things like floors, walls, even fair number of items). Now at some point, things may be such that there are 100 3d models in the arch tree, and it then makes a lot more sense to send those models and have the client deal with them vs sending the 32 variations of each model.
Re: [crossfire] Crossfire release?
On 11/20/10 01:04 AM, Nicolas Weeger wrote: Hello. Been a little more than 6 months since last official release, and I was thinking that trying to get one out before end of the year might be nice. Thoughts/comments? Any list of bugs or other things that must be fixed before a release is made? Things to fix for the next release: - ensure all clients versions are either disconnected with a client too old message or able to create account or at least characters on latest server Client too old may be reasonable - at some point, the older clients really will not work. It isn't feasible of course to test every client with every version of the server, and vice versa. The problem of enforcing versions gets tricky - one does not want to force version 1.60 client with 1.60 release, as everyone with older clients now have to update right then to play. But I will verify that 1.50 client works properly, and if you are playing older than that, probably time to update. - have an official Windows client ; if GTK should be it, actually build and package it (last tests I made showed issues with Glade library) Is that suggesting that maybe the java client should be the official windows client. I haven't looked, so I don't know how easy/hard it would be to take the glade file and make the static config file (old method) - while less than ideal, if there are issues with windows, that may be one approach. I personally do not have a windows dev environment - that is of course one of those things that always makes things harder to work for. - remove metaserver1 support from clients, so players don't go to old obsolete servers Should perhaps metaserver1 support also get removed from server at same time? In that way, the client at least has to be know enough to support metaserver2 to play on newer servers (probably not much difference there, since that support has been there a while). Things to fix someday: - add more quests, link maps or stories ; this would give players some hints on what to do or point to maps they don't know Yes - one other thought I've had, and which many other games do, is have some form of achievements/titles. These may not have any actual in game effect, but to some extent let a player track what they have done. Eg, kill 1000 demons and you get the demon slayer title. Maybe remove the custom title currently in the game, and only let player set their titles to ones they have earned. - make enough quests to nicely level in various skills (eg suite of alchemy- related quests enabling the player to learn recipes and level up) Discussion of that probably gets beyond this message - but some of that also goes into gameplay and other aspects - I certainly think it would be good to have the recipe chains for alchemy be such that one could, through alchemy, reasonably get high experience (this would involve making the basic recipes much more easy to find or perhaps common knowledge (eg, each time you gain a level in alchemy, you learn a recipe for that level). The hard part IMO for quest chains/skill leveling is ideally, you want the process of completely the quest to use the skill in question - having an alchemy type quest which is to get the liver of the boss monster at a bottom of a dungeon is fine, but one really isn't using alchemy (most likely) to solve that quest. A few of those may be reasonable, but I just get the feeling that if too many are about, it might start to feel somewhat artificial. - many more compound graphics - create a Fenx character, and use singing, fight, cast magic, do the same for other races and classes Yes, but I'd almost be tempted that if redoing/adding a lot of graphics get looked at, having an larger image set (64x64 base lets say) would be nice, but that probably gets into the dreamworld below. - fix many broken monsters (hint: ac-70 will make the monster almost invulnerable in melee), balance exp/sp/hp/gr and such Yes - those should get fixed. - fix various Python guild bugs and issues - fix item_power ; some items are more powerful than others with less item_power (eg some rings, I think) ; also item_power is almost useless once you reach level 50, so spread the scale more Some of the idea behind item power was to prevent high level characters from giving low level characters really great items, so fact it becomes less relevant at higher levels would be less a concern. But the real problem behind it is that for probably 99% of the items, it is computed by the server, and it can only make general assumptions on value - certainly some attacktypes are better than others, as are protections. I suspect that within maps which do set item power, it hasn't been done consistently accross the board - mapmaker A's maps are consistent, but mapmaker B may use a higher basic item power than A. In a dreamworld: - better unique map or unique
Re: [crossfire] Crossfire release?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/16/10 10:24 PM, Kevin R. Bulgrien wrote: I don't really know of any serious stability reports out there, though some users seem to be confused by the account / character setup dialogs. I've been working on the walk though for the new account setup, progress so far is located at: http://crossfire.real-time.com/guides/character/summary.html Probably don't want to go in such big hops as to get to 1.100+ is all I have to add to that. On one hand the client changes are significant. On the other, without a corresponding server release, its probably a bit weird to go jumping the client by leaps and bounds. In the past, (can't recall the exact release..) having server release number differ from client release number created new confusion in regards to compatibility of one with the other. So, from that point, we've tried to keep all the release numbers the same. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFM5HvOhHyvgBp+vH4RApMPAKCbhm/s5CovgLbmUsCfgrJSlLHDfACfaPW4 TBglFcPmWguQlWsoYLyRMMU= =OUGY -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire release?
On 11/16/10 08:24 PM, Kevin R. Bulgrien wrote: snip IMO, it is time to ditch gtk-v2.glade as the default. It is becoming a not so uncommon event for a new user to come on IRC and have fits getting the important window panels to show up (inventory in particular). I've had one disappear off IRC after trying hard to help with little success. I'd personally rate this pretty much a necessity. Maybe dealing with that should be a different thread though. I have no issue changing the default to something that is easier to use/works for a larger number of users. I did work to fix the caching of hosts in the metaserver dialog, but there is a bug still left. Somehow the cache list displayed isn't quite right. I haven't followed up to find out what's wrong yet. I'd like to rework the new dialogs. They do not match the style of the other dialogs, and, IMO, with apologies to the designer, ugly. It is not necessary to do so, but already that client has a reputation for its not so elegant looks. I know many of the new dialogs would need some work. I was also caught somewhat in not quite knowing the best/correct size for them - some of the windows would be much better if they were larger (descriptions are scrunched in small area), but at same time, I didn't want to make the windows too large to work on low res displays - I'm not sure what the minimal display resolution we target currently is. As for ChangeLog, I've personally taken to heart an IRC conversation about that document. I have started only logging things there that seem likely to be of end-user interest., and to allow the SVN log to serve as the technical change log. That may be a different discussion - I missed the IRC conversation, but what is really recorded in the changelog could become just significant changes, and minor bug fixes not recorded there. I suppose I just followed the format of most projects where everything is recorded in the ChangeLog to high detail, but some are much more general. One concern I do have about that is to make sure comments recorded for the actual changed files be meaningful. Having a comment in the svn log like 'bug fix' is pretty useless - I'd much rather have the description be something like 'fix possible null pointer reference '. I only bring this up because in many cases, the same entry in the Changelog is what is used in the files. Music is working in GTK-V2 though there is no mechanism to deliver music with the client. I think some work needs to be done to at least define a system-wide location for music and a user-specific location for music. We also have no infrastructure set up to distribute media either. Not sure its worth making a big deal about the new feature at this point. I suspect music will be like sounds - distribution will be in tar files/rpms/whatever. That said, any music files we have should get committed to SVN so they can be distributed. I suspect that music files will change infrequently enough that such a distribution method works fine. But if something more frequent was needed (say you add several new song files and don't want to wait for next official release that may be 6 months away), packing up a new tar archive with the new files and calling it a .1 release or something would probably be fine. Sound/Music may eventually need with respect to possibly fixing old .crossfire folder content, but then maybe one needs to just ditch the legacy files rather than try convert them to the new system. (The old system was severely broken as it used hard-coded absolute paths that could single-handedly disable sound if changes occurred upstream.) I have no issues disabling/breaking old stuff if there is a good replacement - in fact, I'd rather ditch legacy stuff than adding bits of code to try and keep it functional. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire release?
Been a little more than 6 months since last official release, and I was thinking that trying to get one out before end of the year might be nice. Thoughts/comments? 1.50.0 is broken. One cannot create a new character due to a .glade file bug. A release is needed. Technically, a 1.50.1 could consist of a new dialogs.glade file only. The fix is in SVN already, but, I think I'd prefer to see a general release since so much time has passed. Yes, getting one out would be nice to hit a new round of distribution hits to replace the broken client. I don't really know of any serious stability reports out there, though some users seem to be confused by the account / character setup dialogs. Any list of bugs or other things that must be fixed before a release is made? One place where stuff is recorded is: http://wiki.metalforge.net/doku.php/known_client_issues #2938902 crossfire-client-gtk2 has get/take errors https://sourceforge.net/tracker/?func=detailaid=2938902group_id=13833atid=113833 There are a few others in the tracker too... though I'm not sure how significant they are. I think a fair number of them are Windows client issues, but this one is one I run into. IMO, it is time to ditch gtk-v2.glade as the default. It is becoming a not so uncommon event for a new user to come on IRC and have fits getting the important window panels to show up (inventory in particular). I've had one disappear off IRC after trying hard to help with little success. I'd personally rate this pretty much a necessity. Maybe dealing with that should be a different thread though. I did work to fix the caching of hosts in the metaserver dialog, but there is a bug still left. Somehow the cache list displayed isn't quite right. I haven't followed up to find out what's wrong yet. I'd like to rework the new dialogs. They do not match the style of the other dialogs, and, IMO, with apologies to the designer, ugly. It is not necessary to do so, but already that client has a reputation for its not so elegant looks. FWIW, I'd also like to rework the main windows the same way I did the dialogs. I think that would help people find the resize bars more easily. Not critical, but might alleviate issues with gtk-v2.glade somewhat. Likewise, any list of the major changes since last release? Looking at changelog can be a little problematic, as it may not be readily apparent from the notes whether it is a significant/meaningful change. As for ChangeLog, I've personally taken to heart an IRC conversation about that document. I have started only logging things there that seem likely to be of end-user interest., and to allow the SVN log to serve as the technical change log. An important fix for the client is that it should handle backslash vs slash delimited paths properly now when built on windows. Dynamic resize of spells dialog is added. This is pretty significant. A great deal of effort went into populating all the spell help, and the text reflow capability means the dialog is much more useful on a variety of desktop environments. The client has preliminary support for Spellmon 2 (spells that require ingredients), but ingredient listing is not end-user visible at this time. The client now has a 30 second timeout instead of a 3-4 minute lockup if a connection attempt is made to a host/port that does not have a listening server. (Probably 30 seconds is still too long...) Issues with [X] close of dialogs has been improved and segfaults under some window managers are prevented. Delete events are now trapped and ignored to prevent dialogs from disappearing and requiring a client restart to correct the situation. I wonder if the most recently added dialogs are in need of the same fix applied to the account system dialogs. Music is working in GTK-V2 though there is no mechanism to deliver music with the client. I think some work needs to be done to at least define a system-wide location for music and a user-specific location for music. We also have no infrastructure set up to distribute media either. Not sure its worth making a big deal about the new feature at this point. Sound effects are not done at this point, but the infrastructure is technically operational as I can play sound effects in a tweaked development work space, but the server-to-client link is not complete. I think some factoring needs to be done to get a reasonable implementation. All the points made about music are pretty much also true for sound effects. Sound/Music may eventually need with respect to possibly fixing old .crossfire folder content, but then maybe one needs to just ditch the legacy files rather than try convert them to the new system. (The old system was severely broken as it used hard-coded absolute paths that could single-handedly disable sound if changes occurred upstream.) Even with the incomplete implementation, cfsndserv and friend should be release-safe. I figure release should probably be called 1.51,
Re: [crossfire] Crossfire Release Cycles/Methodology
Just a note - I've put a copy of this document, with a few minor changes, on the wiki: http://wiki.metalforge.net/doku.php/crossfire_release_cycle ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Release Cycles/Methodology
I'm not sure about the other systems out there - once can spend a lot of time looking over all the documentation, etc. AS with our last discussion, I'm most inclined to stick with CVS since we know what it does and doesn't have any real major shortcomings (it works right now). I'm in no way CVS/SVN expert (I use both, but I never really played with branches). IMO, if SVN isn't too bad for branches, we should switch. SVN has atomic transactions, that's a great feature, specially with upcoming talk about restructuration and such - makes it much easier to revert commits. Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Release Cycles/Methodology
Also, about restructurations of code, svn unlike cvs does not 'forget' the history of a file when it's moved. I use cvs a lot for work and dureing refactoring of our code (which happens from time to time) we already lost versions of some files because they were deleted / restored / deleted and as result, you have an unconsistent attic (2 files with same name at same directory got deleted, you only have access to latest on in Attic) Nicolas Weeger (Laposte) wrote: I'm not sure about the other systems out there - once can spend a lot of time looking over all the documentation, etc. AS with our last discussion, I'm most inclined to stick with CVS since we know what it does and doesn't have any real major shortcomings (it works right now). I'm in no way CVS/SVN expert (I use both, but I never really played with branches). IMO, if SVN isn't too bad for branches, we should switch. SVN has atomic transactions, that's a great feature, specially with upcoming talk about restructuration and such - makes it much easier to revert commits. Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Release Cycles/Methodology
svn does branching and tagging, and according to this faq (http://subversion.tigris.org/faq.html#merge-using-tags) it does it pretty well. basically svn does this to handle branching and merging copy trunk - myBranch copy myBranch - myBranchMerged modify myBranch at will copy the diff between myBranch and myBranchMerged to trunk CVS on his side does this tag the main branch create a branch from given tag (don't forget to give that branch a name that must be different than tag) modify the branch copy all changes made to branch to main As a result, same number of operation, and svn is 'supposed' to be faster than cvs at this because the operations do not depend on repository size but on change size. I think that because the branch name appear in url, it make it easier for user to checkout a given branch or revision from anonymous svn and the fact branches appear on http browsing (which is not the case of svn) is also a pro for svn. Mark Wedel wrote: Some of SVN big advantages appears to be able to work offline (keeps copy of data you checked out around so you can do diffs without needing connection, as well as ungets). Some of the other features may not make as big a difference to us - ability to use different connection methods (that really is up to the hosting agent) and better binary support. But the fact it doesn't do branching as well as CVS is probably a major shortcoming, especially since we are looking at needing to use branches a lot more. I'm not sure about the other systems out there - once can spend a lot of time looking over all the documentation, etc. AS with our last discussion, I'm most inclined to stick with CVS since we know what it does and doesn't have any real major shortcomings (it works right now). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Release Cycles/Methodology
Nicolas Weeger (Laposte) wrote: Hello. I globally agree, a few points: - Client and server releases will be done at same time, with matching version numbers. - Exception is micro releases, where it may be only the client or only the server released. This supposes client will evolve too. Experience shows client has a development cycle way slower than server. So we may have cases where client doesn't really need to be released. True - OTOH, it isn't really harmful to release the client periodically. Actually, given this release model, the changes in the server will be greatly diminished. If we look back what was done since 1.0, all of the big features would be in the 2.0 target and missing from the 1.x releases. - Major release is done when feature set is complete. That I'm not totally sure I agree. It's nice to agree on a feature set for next major release. But sometimes no one feels working on some point for some months, whereas code moves in another area, enough to warrant a major release. So I'd say we decide on a wanted features list, but we can release a major anyway if enough changes were made. Perhaps ammended that the list can be revisited at various times. If we are talking years between major releases, I think that is a requirement - how can anyone really say what things will be like 18 months from now - things may change such that some new feature/changes is critically needed. Likewise, if there are features on the list that no one is willing to do, it may be reasonable to discuss if those features should really be on that list - if the list is determined by the developers, there should probably be some willingness by the developers to work on those things. I guess the main point is that it should be a surprise to anyone when the release is done. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Release Cycles/Methodology
Mark Wedel wrote: As far as going to something else, I think it would have to be vastly better - sourceforge provides a nice free environment - it keeps things very simple - it is associated with a group, not a single person. Something that is not free or associated with one person can become a problem. Suppose there is some cool site that provides a nice source control package for a relatively nominal amount of money, and I'm willing to pay it. That works great unless I'm hit by a meteorite, and which time, that could just disappear without anyone really knowing why (same points apply to services hosted on a persons private computer, etc - it sounds reasonable, but if something happened to that computer (house burns down), first priority for that person probably isn't getting that server set up again). For such reasons I would agree, we shouldn't go for something that is not free, or associated with one person. My point was more saying that perhaps it would be worth also evaluating the possibility of using some other version control system such as bazaar-ng (personally I think that's a pretty good one, however I don't think it would be a great idea for cf, largely because it becomes rather slow with source trees as large as crossfire, but I was just primarily using that as an example). Personally I currently think that either SVN or CVS are the best options for crossfire, but I just wanted to make a point that other options are worth looking at a little too. In terms of hosting, that is an issue for use of other, the metalforge server may or may not work (don't know if Leaf would or not), however that too has a little bit of those associated with one person potential issues, though it is less significant. One thought, is distributed version control systems would make associated with one person issues less significant, thought it wouldn't eliminate those issues. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Release Cycles/Methodology
Lalo Martins wrote: snip svn criticisms Ahh yes, those are the sorts of SVN issues I've heard about, though I'm not experienced with SVN myself. I believe the idea is to try some proper revision control system like bzr (there's free hosting at launchpad.net; you can host your own using only ssh and a webserver), git/cogito (used by the kernel and many freedesktop.org packages; I'm sure there must be free hosting somewhere) or darcs (again, needs only ssh and http to host). One little note, bzr I find to be rather nice, however I find it's a bit annoyingly memory and cpu intensive on source trees as large as cf. git/cogito looks interesting, the tools seem pretty nice from what little I've looked at, though it will be a bit of pain under windows (and we do have a couple windows-using developers) as under windows it requires cygwin. One other thought, darcs looks like an interesting one too, however the fact that it's written in hacksel makes it a bit of a pain to compile if one can't get binaries for one's system. Personally I'm thinking just sticking with CVS is best though, largely due to sticking with sf being easiest. I'm now thinking that SVN wouldn't be too bad, but wouldn't be worth switching from CVS to use unless one has some significant reason. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Release Cycles/Methodology
Some of SVN big advantages appears to be able to work offline (keeps copy of data you checked out around so you can do diffs without needing connection, as well as ungets). Some of the other features may not make as big a difference to us - ability to use different connection methods (that really is up to the hosting agent) and better binary support. But the fact it doesn't do branching as well as CVS is probably a major shortcoming, especially since we are looking at needing to use branches a lot more. I'm not sure about the other systems out there - once can spend a lot of time looking over all the documentation, etc. AS with our last discussion, I'm most inclined to stick with CVS since we know what it does and doesn't have any real major shortcomings (it works right now). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Crossfire Release Cycles/Methodology
Per the recent discussion on code reorganization and what goes in what release, this document is an attempt to gather the points raised and make it into a formal document that can be included in the code or put on the wiki. This document does not attempt to justify or explain why different things are done for reasons of brevity - if we actually want every developer to read it, we want to stick to the what the rules are, and not as much how we arrived at those rules. If I missed anything, or there is strong disagreement on any of these points, speak up. . -- - Crossfire versioning is described as major.minor.micro - 2.3.4 means major version 2, minor 3, micro 4 - The main (head) of the CVS branch contains what will be the next major release. - A branch for the minor releases will be made when a major release is done - It is from this stable-major branch that future minor releases are made. - If a micro release is necessary, it will be branched from the stable-major branch, as stable-major-minor. - The RE may choose to make a branch for an upcoming minor release to limit changes, as stable-major-minor. - Minor releases will be made at periodic intervals (2-4 months apart). - Micro releases will only be done if an immediate release is necessary due to a critical bug, and waiting for the next minor release is not an option. - All releases will be symbolically tagged as rel-major-minor-micro - There is no practical upper limit to minor or micro versions - crossfire 1.16.22 is valid. - Client and server releases will be done at same time, with matching version numbers. - Exception is micro releases, where it may be only the client or only the server released. - Public servers expected to run the stable branch, not the head branch. - stable branch will be made for all arch, maps, client, and server components of crossfire. - What goes in each version of Crossfire: - All changes go into the main head branch, what will become the the next major release. - Smaller features/additions will also be done in the stable branch. - Developer discretion on whether to make change to stable branch in addition to head branch - Bug fixes go in both branches. - Developer making bug fix responsible for updating both branches - Following changes can only be made in the head (next major) branch: - Changes that break compatibility - Changes that make signficant changes to the code. - Removal of programs (discontinue support for a client as an example) - Changing name of executables. - Feature set of next major release to be discussed by developers. - List of proposed changes sent to mailing list. - Developers comment, decide priorities on list of features for next major release. - For major features, brief design document needs to be written, describing the feature, why it is important, and in broad terms, how it will be done. - All changes to protocol must have a design doc, no matter how small. - Design doc must be done before changes are commited - no writing design doc after code is written - Major release is done when feature set is complete. - For 2.0, smaller list of features should be the criteria since this change of release strategy is happening later in the 1.x release cycle. -- Open Issues: - Should we switch to SVN? Switching repositories at same time as switching what the head branch means would make the most sense. - Need some way to drive development - need some way to make sure items on TODO list for next release get done, and that developers just don't work on cool features they want that may not match TODO list. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Release Cycles/Methodology
Mark Wedel wrote: Per the recent discussion on code reorganization and what goes in what release, this document is an attempt to gather the points raised and make it into a formal document that can be included in the code or put on the wiki. snipped the large list Those rules seem to make alot of sense to me. I can't think of any disagreement I have with them. -- Open Issues: - Should we switch to SVN? Switching repositories at same time as switching what the head branch means would make the most sense. I agree that when switching what the head branch means makes the most sense, however I'm not sure that to SVN would be a great type of move to me. SVN from what I've seen does address some of CVS's weaknesses, however I have heard that the way it handles branching for example is ugly. Could someone with more experience with SVN comment on branching in SVN? Also, if we are willing/able to move off of sf.net for version control, it might be worth considering other version control options (I personally think that if we don't use either SVN or CVS, we should see if we can set up a read-only CVS or SVN mirror for people to download off of who don't have the other type of version control software.) - Need some way to drive development - need some way to make sure items on TODO list for next release get done, and that developers just don't work on cool features they want that may not match TODO list Well, the best method of dealing with this I've seen, is with how many projects set things like Blocking 2.0 in their bugzilla system. We might be able to use either categories or priority with the sf.net tracker, however that seems hackish to me and wouldn't be the clearest. That said, I think if we are to continue using the sf.net tracker, it would be best to use that for TODO goals, however I think it may be worth considering moving off of sf.net for bug tracking. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
