Overview figure:

Main points:

• Branches
• Trunk: main branch, for API and model changes and new code development.
• Stable: stable side branch for production code, has a stable API.
• Legacy: For merges that require major backwards compatibility a pre-merge branch is kept.
  
• Repositories
• Sourceforge and the biochem ccpn_int will follow this structure
• recoord and extendNmr (at cvsebi) will not follow this structure, though they will be tagged at the same time as the ccpn_ and stable_ tags.
  
• Merges
• These should happen when the new features and code in the trunk are stable and ready to be incorporated into the stable branch. In other words, when trunk is in working order and it is necessary for stable to have access to the new API features.
• The first step in this process is merging stable into trunk. Both branches should be tagged first so there is an easy point to go back to in case things go wrong.
  
• After the merge, the trunk should be extensively tested.
• A complete list of all API/model changes should be available for all developers at this point!
  
• Before merging trunk back into stable, the trunk version is tagged again (few, preferably no, changes should've been made to stable during this time).
• Detailed instructions are available.
  
• CVS tag names
• External releases get a special tag: release_<version>_<releaseVersion>, for example release_2_0_6_1.
• The pre-merge tags for stable and trunk for the merge that happens after both branches have been running in parallel after the ccpn_2_0_4 tag would be stable_2_0_4 and trunk_2_0_4.
• After the initial merge, a merge_<version> tag is done in trunk (not shown on figure).
  
• After the merge is tested, the trunk gets a ccpn_<newVersion> tag.
• After stable is updated, it gets a ccpn_<newVersion>_stable tag.
• Data Compatibility
• Most merges can manage with minor compatibility. These are done during XML I/O with no need for old code. The latest pre-merge tag (e.g. stable_2_0_4) is used for compatibility testing and for checking and fixing of old data files.
• Merges with particular tricky changes need major compatibility code, involving the use of the pre-merge code at run time. Here there must be a branch instead of (or corresponding to) the pre-merge tag (e.g. stable_2_0_4), to allow for bug fixes in compatibility code. The naming of these branches is to be decided.