In this section we hope to explain how our project conducts itself. Not everything is a steadfast rule, but more of a guiding principle. If you're unsure feel free to ask. We want to have just as much fun developing as we want our users to have playing KardsGT. Our goal is to have as many games as possible that follow Hoyle's Rules of Games. Our current direction is to add the basic version of each game, and then add the variations of each game.
Until the release of KardsGT 1.0 all aspects of the programme are subject to change between each release.
The versioning number system we use is the standard major.minor.patch structure. The CVS structure has each major and minor release on their own branch. These branches are to be stable upon release and should only include bug fixes from then on. In general, once a new release is made the previous release is no longer maintained. The individual patches are not on their own branch as they are only needed to know what bug fixes were made. The development branch is on the base of the system. Once a release is made the version for KardsGT on the base CVS is incremented to the next version.
The development process for KardsGT is:
Each of the phases are elaborated below.
- feature freeze
- code freeze
- release candidates
During this phase we invite all developers to discuss what features we want for the next release, go over some of the requests from our users, etc. At this point each developer should make a commitment to a feature he wishes to develop. Each feature should be added to the task list, assigned to the developer who made the commitment, and the due date set.
We have a feature freeze for each major and minor release. During a feature freeze no significant functionality can be added to KardsGT. During this time KardsGT will be improved and perfected. Each of the features for the next release are listed in the road map.
Each major and minor release will eventually end up in a code freeze before the tentative release date. Once KardsGT has entered a code freeze, all changes to the code is discouraged and only changes that fix known bugs is permitted.
During this stage we'll have a couple Release Candidates that we have available for testing. If no major problems occur that haven't already been addressed, then a release will occur. If there is a major problem that will delay the release significantly (significantly being missing our release date over 30 days), then a release will still occur, but a note of it will be made in the TODO list. If we wont be delayed significantly, then we'll fix the problem and issue another Release Candidate. This process will occur until we're satisfied with the release quality or have ran out of time.
Before KardsGT makes a stable release every method and class variable must have documentation, all help information must be up to date. Any game information changes must be made back to the Wikipedia articles, if appropriate. We use doxygen for all of our documentation.
All website documentation is also reviewed at this time, and updated accordingly.
Each stable release will be maintained for bug fixes only for duration of the next development cycle. A new release will be made for any of the bug fixes, and for each bug fix the patch number is incremented. These fixes can also be found on the branch on the CVS.
Joining the Team
Anyone who is a member of Savannah is allowed to submit patches through our development site. Joining Savannah is very simple and quick. We require Savannah membership to increase the accountability of patch submissions.
The patches don't have to follow the coding style guidelines, but it would be greatly appreciated. To increase the likelihood of your patch being accepted please do the following:
If you change multiple things in KardsGT, submit a patch for each feature, bug fix, etc that is changed.
Include an explanation in your submission
Include useful comments in your code
All patches should be done using the diff command. Be sure to use the -u format for the patch.
Complete instructions can be found at the
To gain membership to the development team, we would ask that you first submit patches or other work if you're not a programmer a few times. This way you can see if you want to work with us, and we can do the same. :) All members start out at the level of a technician. Everything we do is either done under the GPL if it's in the programme, or under the GFDL if it's in the help system, this is a requirement of membership.
When joining this project there are few commitments. We require that when we switch to any future version of the GNU GPL License, you agree to that switch. We would want you to be on the mailing lists, and to participate in the discussions there.
If you're a developer:
You can start anywhere, there's a lot left to do. Just keep in mind that the goals are to keep the logic, the rules, and the graphical parts of the games as separated as possible to ease development and testing. You could work on the present TODO list which is the best idea if you're just starting out. The TODO list is only created at the time of each release, so check on the development site before you start to work on the TODO item to see if someone is presently working on that item. If you add a game to the KardsGT project, we would expect that you would want to maintain your game code.
If you're an artist:
All of our artwork is currently stored on our CVS as Krita files. The purpose behind storing the actual image file, as opposed to a PNG file is that people who wish to modify the image can do so and get the same level of quality results. All the images are also released under the GPL, as stated above. You are free to use what ever you want to create your images, but a Krita file is the only one allowed to be placed on the CVS. Arrangements can be made if you do not have access to Krita. When you add a new image to the project, be sure to update the NOTICE file.
With the aspirations we have for this project we need all kinds of people:
No matter what your function is in the project, all members have a say in the development of the project.
- Graphics programmers
- Website maintainer
To ease development and reading the code we are following the ANSI coding style
. If you're developing in KDevelop you can automatically format your code to fit our style.
© 2006 - 2008 by John Schneiderman, released under the
Last Updated: 16 Aug 2008