project/BRANCHES-AND-TAGS.md

   1 Branches and tags
   2 =================
   3
   4 Note: details of the release process for the Engine are documented in the
   5 [RELEASE-CHECKLIST](https://github.com/docker/docker/blob/master/project/RELEASE-CHECKLIST.md).
   6
   7 # Branches
   8
   9 The docker/docker repository should normally have only three living branches at all time, including
  10 the regular `master` branch:
  11
  12 ## `docs` branch
  13
  14 The `docs` branch supports documentation updates between product releases. This branch allow us to
  15 decouple documentation releases from product releases.
  16
  17 ## `release` branch
  18
  19 The `release` branch contains the last _released_ version of the code for the project.
  20
  21 The `release` branch is only updated at each public release of the project. The mechanism for this
  22 is that the release is materialized by a pull request against the `release` branch which lives for
  23 the duration of the code freeze period. When this pull request is merged, the `release` branch gets
  24 updated, and its new state is tagged accordingly.
  25
  26 # Tags
  27
  28 Any public release of a compiled binary, with the logical exception of nightly builds, should have
  29 a corresponding tag in the repository.
  30
  31 The general format of a tag is `vX.Y.Z[-suffix[N]]`:
  32
  33 - All of `X`, `Y`, `Z` must be specified (example: `v1.0.0`)
  34 - First release candidate for version `1.8.0` should be tagged `v1.8.0-rc1`
  35 - Second alpha release of a product should be tagged `v1.0.0-alpha1`