Subversion is our code repository and working hub of the GN codebase. We use Subversion to deposit and manage code throughout the cycle of development: writing, testing, releasing, and updating. The general strategy is that the trunk holds all code associated with GN. The complete release is copied into a branch for testing, and after a new branch has passed all tests, the branch is copied to tags/.

1. Planning

GN developers and users start by having ideas and discussing options for new features and improvements. Some ideas percolate up from users of Roundup or from discussions during demonstrations and projects. The GN team considers ways to implement ideas for new functions and databases. Some functions do not require any changes to relational database tables, but others may require significant new database tables or relatively major overhauls of relations among those tables. We evaluate the cost-benefits of a new function?will it require an hour of code tweaks and benefit virtually all users (a win) or will it take months of reorganizing of database tables and lots of new Python code and benefit one expert user (a loss). The list of proposed new functions (and datasets) is then ranked, and new projects are assigned to programmers. This process is relatively informal and is currently (May 2007) managed by Rob Williams. We try to estimate the time of a new beta release, for example, two months. In the plan, we need to leave some time on documentation and test.

2. Developing

Each programmer checks out a working copy of the GN codebase. Programmers develop code on top of their working copies, and check in the changes of the codebase back to the repository at gn/trunk. Changes that require the addition of new database tables should be made in consultation with the lead programmer of GN (currently Hongqiang Li). Apparently minor changes in tablebase tables can interact in unexpected ways with the current Python code and may produce a range of errors. This is partly due to poor structure of the Python code and its interactions with the database tables and fields.

3. Testing

After the development reach our goals as we planned, we copy the new version (say, 1.0) of the code in the repository from gn/trunk to gn/branches/1.0. Next time we copy our 2.0 version to gn/branches/2.0, and so on. The codebase in the branches/ will be used for testing. We check out the new version from the branches/1.0 to our beta web site (http://web2qtl.utmem.edu) and test. In the meantime, new development can proceed in each /trunk.

If we find any bugs, we fix them on the beta web site and check in the changes into the branches/1.0 in the repository. We may also need to merge the changes made in branches/1.0 to /trunk.

Zhaohui Sun also has some ideas about our GNTestingApproaches, which is important but is still very weak in the GN project.

4. Release

After the new beta version passes all tests, we copy the new version of the code in the repository from gn/branches/1.0 to gn/tags/release060818. The name of the release tag indicates the release date. We release new software to the working website (www.genenetwork.org) by checking out a copy from gn/tags/release060818 in the repository.

5. Maintainence

If any bugs are found in our working web site (www.genenetwork.org), debugging should first be carried out in the beta site (webqtl.utmem.edu). Change will be checked into gn/branches/1.0/ and then gn/trunk/ if neccessary. The working copy in www.genenetwork.org needs to be updated based on branches/1.0. If neccessary, a new release copy may be produced (ie., tags/release060818.1).

The process is repeated. These steps can overlap with others, and they can happen in parallel.

Related Documents

• How to install a working copy for development - for programmers
• How to install Genenetwork main site from subversion

-- ZhaohuiSun - 17 Aug 2006