Development Policy

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.

CVS Structure

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.

Development Cycle

The development process for KardsGT is:
  1. planning
  2. feature freeze
  3. code freeze
  4. release candidates
  5. documentation
  6. maintenance
Each of the phases are elaborated below.

Planning

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.

Feature Freeze

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.

Code Freeze

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.

Release Candidates

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.

Documentation

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.

Maintenance

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

Patches

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:

Patching Instructions

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 Creative Commons .

Membership

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.

Joining commitments

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.

People Needed

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.

Coding Style

To ease development and reading the code we are following the ANSI coding style guidelines . If you're developing in KDevelop you can automatically format your code to fit our style.
Valid HTML 4.01! Valid CSS! © 2006 - 2008 by John Schneiderman, released under the GNU FDL .
Last Updated: 16 Aug 2008