Release process

The formal release process is documented in subversion (see Release Criteria for location).

The technical mechanics of a release are largely scriptable, and therefore not worthy of a bunch of wiki pages; please consult the source and READMEs of cca-release-tools as they become available. The svn repository is web-browseable.

The social mechanics of any software release are the hard part, and go as follows:

1. Developers and management negotiate a set of targets for a given release.
2. Once the targets are met, developers produce a test bundle and documentation of major changes that may impact current users. Significance of release should be categorized, regardless of numbering, as major (critical new features and potentially some breakage for most users) or minor (typically bug fixes and new features affecting only a few). As  the cca-tools product is a bundling of many other products, the details of tagging and branching individual pieces will be documented and performed separately in those products. The cca-tools release manager for a given release will coordinate or perform the details of repository tagging.
   
3. Management identifies beta-testers independent of the developers to determine if the bundle and its new features (a) work, and (b) are worth bothering with as a release. It should be unlikely that the testers will say 'no' to (b) if due care was exercised in step 1.
4. Release is made with much fanfare and, after delta-t, much recrimination.
5. A release characterized as major will be fully supported until the next major release. A release characterized as minor will be fully supported until the next minor or major release, whichever is sooner.