Workflow
The gambit repository in gambitproject contains the main, "official" development of Gambit. Individual developers should work in their own sandbox repositories, and send pull requests or patches when fixes and features are ready for consideration for integration.
The basic ideas of workflow management are adapted from the workflows used in the development of git itself; see http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html for an outline.
There are two long-lived mainline branches in the gambit repository:
- master: This contains all changes which are intended for inclusion in the next release.
- maint: This contains all changes from the last release, plus any needed bug fixes, backports, and so forth for maintenance releases from the previous main release.
Past releases are always tagged, with tags in the form v0.2010.09.01 (for the release numbered 2010.09.01).
To decide where to branch your own work from, consider these principles:
- If you're working on a bugfix or other change that should go into a maintenance release of the previous version, branch from 'maint'.
- If you're working on a fix or feature for the next release, branch from 'master'.
- If you want to work on a fix or feature without having to deal with other changes being introduced in 'master', consider branching from the last version tag.
It is strongly recommended that each logically-distinct change be developed in its own topic branch (see, e.g., http://progit.org/book/ch3-4.html). Ideally, topic branches should correspond to an issue in the issue tracker, to help organize who is working on what.
Gambit uses the "integration manager workflow" (http://progit.org/book/ch5-1.html). Ted Turocy (T.Turocy@uea.ac.uk; github ID tturocy) acts as integration manager for the main Gambit repository.