Releasing DOs

A project team can use DO versions to make its product (for example, a library) available to other teams. Typically, the team establishes a release area in a separate VOB.

For example:

  • A library is built by its project team in one location--perhaps /vobs/monet/lib/libmonet.a.
  • The team periodically releases the library by creating a new version of a publicly accessible element--perhaps /vobs/publib/libmonet.a.

You can generalize the idea of maintaining a development release area to maintaining a product release area. For example, a Release Engineering group maintains one or more release tree VOBs. The directory structure of the trees mirrors the hierarchy of files to be created on the release medium. (Because a release tree involves directory elements, it is easy to change its structure from release to release.) A release tree can be used to organize Release 2.4.3 as follows:

  1. When an executable or other file is ready to be released, a release engineer checks it in as a version of an element in the release tree.
  2. An appropriate version label (for example, REL2.4.3) is attached to that version, either manually by the engineer or automatically with a trigger.
  3. When all files to be shipped have been labeled in this way, a release engineer configures a view to select only versions with that version label. As seen through this view, the release tree contains exactly the set of files to be released.
  4. To cut a release tape, the engineer issues a command to copy the appropriately configured release tree.