Skip to end of metadata
Go to start of metadata

A cookbook approach to creating tags, from release branches, for a CollectionSpace release.  What's in a version name?  Follow this link:

About tags and tagging

A "tag" is a snapshot of a software source code tree at a point in time. The process of "tagging" - that is, creating a tag - for a CollectionSpace release effectively creates a point-in-time snapshot of the source code for that release.

For example, the v4.4 tag represents the snapshot of CollectionSpace source code corresponding to the CollectionSpace v4.4 release. A CollectionSpace system running release v4.4 will be based on the source code from the v4.4 tag, before factoring in any configuration changes, code customization, or software patches that might have been subsequently applied to that system.

Tagging a release
  1. Make a new enclosing folder and move into it:

  2. Retrieve each layer's source code into local working directories:

  3. Within each directory in turn; that is, alternately within each of the services, application, etc directories created by the git clone command above:
    1. Change into the appropriate directory; e.g. for services:

    2. Fetch all remote branches:

    3. Verify that the tag you're creating doesn't already exist:

    4. Check out the remote (from GitHub) release branch into a local branch; e.g. if that release branch were named v4.5-branch:


      Making the name of the local branch different from that of the remote release branch can help avoid ambiguity for both humans and Git.

    5. Make an annotated tag from that local branch (and hence effectively from the contents of the current, remote release branch); e.g.

    6. Push the new tag to GitHub

    7. Verify on GitHub that the tag exists:
Optional summary-level verification of release contents
  1. For each layer:
    1. Download the tag release's archive file (.zip or .tar.gz) from GitHub; e.g from:

    2. Explode (expand) that archive file.
    3. Move to the layer's local working directory.
    4. Perform a directory 'diff' between your working directory containing your local branch (e.g. v4.5-branch) and the folder created from exploding GitHub's archive file, using your favorite directory diff tool (e.g. KDiff3, bbdiff for Mac OS X BBEdit users, etc.). These should be identical.
    5. In your working directory, check out the master branch.

    6. Perform another directory 'diff' between your working directory containing your master branch and the folder created from exploding GitHub's archive file. These should differ.

See also

Creating a Release Branch

  • No labels

1 Comment

  1. A note about why the tagging approach above was chosen:

    It appears to be simpler and less error prone to start fresh with new local working directories (without build artifacts, un-tracked or uncommitted changes, etc.), especially when doing the (optional) directory diffs as a sanity check after tagging.

    This process also gives you a set of working directories from which you can build and deploy, to create a candidate tarball for that release.