...
- Clone container and all contents from git into working directory
- Start with distribution of tagged release (including source) in working directory; clone individuals subpackages to replace distributed version in working directory.
- Push changes to GitHub for purpose of backup, sharing with other developers (e.g. on a branch?)
- New code ready for production (e.g. push or merge into master branch)
- Tag a subpackage
- Tag container and all subpackages (and subsubpackages) with a release candidate tag (e.g. ScienceTools-HEAD-1-2345)
- Tag container and all subpackages (and subsubpackages) with a release tag (e.g. ScienceTools-11-4-5)
Automated
As long as all code changes and tags are synced back to CVS the Release Manager can continue to handle all functions just as it has been, but it's worthwhile thinking about the operations it now does which would be impacted if it had to interface to a git repository instead.
- Mechanism to determine contents of a container.
- For release and release candidate builds the file packageList.txt should do. Could perhaps make it serve for LATEST as well with some minor changes to the file or reinterpretation.
- Clone container and all contents from git repository into working directory
- Detect creation of new subpackage (or subsubpackage) tag, which acts as trigger for LATEST
- Detect creation of new release candidate or release tag