github.com/tompao/docker@v1.9.1/project/RELEASE-PROCESS.md (about)

     1  # Docker Release Process
     2  
     3  This document describes how the Docker project is released. The Docker project
     4  release process targets the Engine, Compose, Kitematic, Machine, Swarm,
     5  Distribution, Notary and their underlying dependencies (libnetwork, libkv,
     6  etc...).
     7  
     8  Step-by-step technical details of the process are described in 
     9  [RELEASE-CHECKLIST.md](https://github.com/docker/docker/blob/master/project/RELEASE-CHECKLIST.md).
    10  
    11  ## Release cycle
    12  
    13  The Docker project follows a **time-based release cycle** and ships every nine
    14  weeks. A release cycle starts the same day the previous release cycle ends.
    15  
    16  The first six weeks of the cycle are dedicated to development and review. During
    17  this phase, new features and bugfixes submitted to any of the projects are
    18  **eligible** to be shipped as part of the next release. No changeset submitted
    19  during this period is however guaranteed to be merged for the current release
    20  cycle.
    21  
    22  ## The freeze period
    23  
    24  Six weeks after the beginning of the cycle, the codebase is officially frozen
    25  and the codebase reaches a state close to the final release. A Release Candidate
    26  (RC) gets created at the same time. The freeze period is used to find bugs and
    27  get feedback on the state of the RC before the release.
    28  
    29  During this freeze period, while the `master` branch will continue its normal
    30  development cycle, no new features are accepted into the RC. As bugs are fixed
    31  in `master` the release owner will selectively 'cherry-pick' critical ones to
    32  be included into the RC. As the RC changes, new ones are made available for the
    33  community to test and review.
    34  
    35  This period lasts for three weeks.
    36  
    37  ## How to maximize chances of being merged before the freeze date?
    38  
    39  First of all, there is never a guarantee that a specific changeset is going to
    40  be merged. However there are different actions to follow to maximize the chances
    41  for a changeset to be merged:
    42  
    43  - The team gives priority to review the PRs aligned with the Roadmap (usually
    44  defined by a ROADMAP.md file at the root of the repository).
    45  - The earlier a PR is opened, the more time the maintainers have to review. For
    46  example, if a PR is opened the day before the freeze date, it’s very unlikely
    47  that it will be merged for the release.
    48  - Constant communication with the maintainers (mailing-list, IRC, Github issues,
    49  etc.) allows to get early feedback on the design before getting into the
    50  implementation, which usually reduces the time needed to discuss a changeset.
    51  - If the code is commented, fully tested and by extension follows every single
    52  rules defined by the [CONTRIBUTING guide](
    53  https://github.com/docker/docker/blob/master/CONTRIBUTING.md), this will help
    54  the maintainers by speeding up the review.
    55  
    56  ## The release
    57  
    58  At the end of the freeze (nine weeks after the start of the cycle), all the
    59  projects are released together.
    60  
    61  ```
    62                                          Codebase              Release
    63  Start of                                is frozen             (end of the
    64  the Cycle                               (7th week)            9th week)
    65  +---------------------------------------+---------------------+
    66  |                                       |                     |
    67  |           Development phase           |    Freeze phase     |
    68  |                                       |                     |
    69  +---------------------------------------+---------------------+
    70                     6 weeks                      3 weeks
    71  <---------------------------------------><-------------------->
    72  ```
    73  
    74  ## Exceptions
    75  
    76  If a critical issue is found at the end of the freeze period and more time is
    77  needed to address it, the release will be pushed back. When a release gets
    78  pushed back, the next release cycle gets delayed as well.