Release Branching

This is a proposal on how to manage tagged releases, and patches to same.

A "release" is defined by a tag of a checkout package that follows the CMT tag/version convention. (There appears to be no description in the workbook?)

We distinguish patches to existing releases (which are, confusingly, also releases) with an appended "p",
e.g. if v7r4p1 would be a patch to release v7r4.

Such a patch release will actually be a tag of a branch of the checkout package, which starts with the base release. This allows updating of the HEAD of the checkout package, and new HEAD builds, independently of the patch.

Procedure following a MAIN branch tag

  1. Apply the tag, e.g. v7r4 to the HEAD, on the MAIN branch, of the checkout package, e.g. GlastRelease
  2. Create a branch tag as well, e.g. GRv7r4
  3. Generate branch tags on allthe packages used, or checked out, by the checkout package. Apparently, given that the name does not begin with our standard "v", these are not confused with ordinary CMT tags.
  • No labels

1 Comment

  1. Toby Burnett

    [

    Unknown macro: {toby}

    I tried, by hand, a branch tag on DataChallenge, using a tag GRv7r3p1, which is the GR branch that we happen to be using, inconsistent with the above a bit. Perhaps because it is a branch tag, or the tag does not start with "v", is was not recognized by RM as a proper tag, as desired.