github.com/sijibomii/docker@v0.0.0-20231230191044-5cf6ca554647/project/BRANCHES-AND-TAGS.md (about)

     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`