...
In general, we aim to improve the experience for users while also improving the underlying code base to support long-term development and make it easier for new developers to contribute.
Development
...
Process and Version Control
The Genoviz project uses Subversion for version control and managing the release cycle.
Note that the repository contains multiple branches and a main trunk of development.
There are two types of branches - release branches and development branches.
Release branches have names like "igb_6_4" and correspond to major releases of the software we have made for end users. These should never be removed from the repository and should not every be touched except by the group managing the release. (As of this writing, this is the development team at UNC Charlotte led by Ann Loraine. If you have any questions about this, contact her.)
Development branches are development workspaces and may ultimately be merged backed into the trunk provided they pass testing. If you have a great new idea for an IGB feature or change the the user interface, first make a branch and implement your changes there. DO NOT develop on the trunk unless your proposed new feature is unlikely to introduce many new bugs to other features. If you think your proposed change is unlikely to cause any bugs on the trunk and you don't think creating a branch is necessary, contact . the IGB developers list to affect the system or user experience in a dramatic way. The only developers who should develop on the trunk are Any new features must be thoroughly tested before being merged back to the trunk. If you do not have the personnel to test, then the Loraine group is willing to help you, but please be aware that our resources are limited. If we begin the testing process and find lots of bugs that you should have caught yourself, we will halt the testing process. They will ultimately be removed from the repository following a merge.
The main trunk of development should not be used to "try things out" or experiment with new ideas and architectures. If you want to try something new that is likely to cause many other features to break, then first make a branch and develop it there. Only developers with a lot of experience working with the IGB code base should check in changes to the trunk.
Many users are building the code on the trunk and should not be changed unless
- Development phase - Only conservative changes unlikely to introduce many new bugs are made on the trunk. Developers working on radical changes to the code base should develop on a branch, merging changes from the trunk as they go. Following testing, changes from the branch may be merged into the trunk and the branch discarded. See Version Control with Subversion, Chapter 4. Branching and Merging.
- Branching the code - development proceeds "on the trunk" and "on the branch." Only minor "bug fix" changes are made to the branch.
- Alpha release - all known bugs we plan to fix are fixed on the branch (and trunk), and we set up an IGB "pre-release" download page for the IGB community to try out the new software, give us feedback. Testing continues.
- Beta release - the new version of IGB is released "in beta" and becomes the major IGB available from the main Java Web Start download set at bioviz.org/igb. Sites that use the Bioviz Java Web Start pages on their sites also pick up the new changes. (This includes Affymetrix, Huntsman Cancer Institute, and other sites.) Testing continues.
- Final release - the official release of the new IGB version happens. Meanwhile, and any bug reports from the community are addressed. "Bug fix" (minor) releases may also occur, as needed.
...