github.com/demonoid81/moby@v0.0.0-20200517203328-62dd8e17c460/project/PATCH-RELEASES.md (about)

     1  # Docker patch (bugfix) release process
     2  
     3  Patch releases (the 'Z' in vX.Y.Z) are intended to fix major issues in a
     4  release. Docker open source projects follow these procedures when creating a
     5  patch release;
     6  
     7  After each release (both "major" (vX.Y.0) and "patch" releases (vX.Y.Z)), a
     8  patch release milestone (vX.Y.Z + 1) is created.
     9  
    10  The creation of a patch release milestone is no obligation to actually
    11  *create* a patch release. The purpose of these milestones is to collect
    12  issues and pull requests that can *justify* a patch release;
    13  
    14  - Any maintainer is allowed to add issues and PR's to the milestone, when
    15    doing so, preferably leave a comment on the issue or PR explaining *why*
    16    you think it should be considered for inclusion in a patch release.
    17  - Issues introduced in version vX.Y.0 get added to milestone X.Y.Z+1
    18  - Only *regressions* should be added. Issues *discovered* in version vX.Y.0,
    19    but already present in version vX.Y-1.Z should not be added, unless
    20    critical.
    21  - Patch releases can *only* contain bug-fixes. New features should
    22    *never* be added to a patch release.
    23  
    24  The release captain of the "major" (X.Y.0) release, is also responsible for
    25  patch releases. The release captain, together with another maintainer, will
    26  review issues and PRs on the milestone, and assigns `priority/`labels. These
    27  review sessions take place on a weekly basis, more frequent if needed:
    28  
    29  - A P0 priority is assigned to critical issues. A maintainer *must* be
    30    assigned to these issues. Maintainers should strive to fix a P0 within a week.
    31  - A P1 priority is assigned to major issues, but not critical. A maintainer
    32    *must* be assigned to these issues.
    33  - P2 and P3 priorities are assigned to other issues. A maintainer can be
    34    assigned.
    35  - Non-critical issues and PR's can be removed from the milestone. Minor
    36    changes, such as typo-fixes or omissions in the documentation can be
    37    considered for inclusion in a patch release.
    38  
    39  ## Deciding if a patch release should be done
    40  
    41  - Only a P0 can justify to proceed with the patch release.
    42  - P1, P2, and P3 issues/PR's should not influence the decision, and
    43    should be moved to the X.Y.Z+1 milestone, or removed from the
    44    milestone.
    45  
    46  > **Note**: If the next "major" release is imminent, the release captain
    47  > can decide to cancel a patch release, and include the patches in the
    48  > upcoming major release.
    49  
    50  > **Note**: Security releases are also "patch releases", but follow
    51  > a different procedure. Security releases are developed in a private
    52  > repository, released and tested under embargo before they become
    53  > publicly available.
    54  
    55  ## Deciding on the content of a patch release
    56  
    57  When the criteria for moving forward with a patch release are met, the release
    58  manager will decide on the exact content of the release.
    59  
    60  - Fixes to all P0 issues *must* be included in the release.
    61  - Fixes to *some* P1, P2, and P3 issues *may* be included as part of the patch
    62    release depending on the severity of the issue and the risk associated with
    63    the patch.
    64  
    65  Any code delivered as part of a patch release should make life easier for a
    66  significant amount of users with zero chance of degrading anybody's experience.
    67  A good rule of thumb for that is to limit cherry-picking to small patches, which
    68  fix well-understood issues, and which come with verifiable tests.