# Docker patch (bugfix) release process
 
 Patch releases (the 'Z' in vX.Y.Z) are intended to fix major issues in a
 release. Docker open source projects follow these procedures when creating a
 patch release;
 
 After each release (both "major" (vX.Y.0) and "patch" releases (vX.Y.Z)), a
 patch release milestone (vX.Y.Z + 1) is created.
 
 The creation of a patch release milestone is no obligation to actually
 *create* a patch release. The purpose of these milestones is to collect
 issues and pull requests that can *justify* a patch release;
 
 - Any maintainer is allowed to add issues and PR's to the milestone, when
   doing so, preferably leave a comment on the issue or PR explaining *why*
   you think it should be considered for inclusion in a patch release.
 - Issues introduced in version vX.Y.0 get added to milestone X.Y.Z+1
 - Only *regressions* should be added. Issues *discovered* in version vX.Y.0,
   but already present in version vX.Y-1.Z should not be added, unless
   critical.
 - Patch releases can *only* contain bug-fixes. New features should
   *never* be added to a patch release.
 
 The release captain of the "major" (X.Y.0) release, is also responsible for
 patch releases. The release captain, together with another maintainer, will
 review issues and PRs on the milestone, and assigns `priority/`labels. These
 review sessions take place on a weekly basis, more frequent if needed:
 
 - A P0 priority is assigned to critical issues. A maintainer *must* be
   assigned to these issues. Maintainers should strive to fix a P0 within a week.
 - A P1 priority is assigned to major issues, but not critical. A maintainer
   *must* be assigned to these issues.
 - P2 and P3 priorities are assigned to other issues. A maintainer can be
   assigned.
 - Non-critical issues and PR's can be removed from the milestone. Minor
   changes, such as typo-fixes or omissions in the documentation can be
   considered for inclusion in a patch release.
 
 ## Deciding if a patch release should be done
 
 - Only a P0 can justify to proceed with the patch release.
 - P1, P2, and P3 issues/PR's should not influence the decision, and
   should be moved to the X.Y.Z+1 milestone, or removed from the
   milestone.
 
 > **Note**: If the next "major" release is imminent, the release captain
 > can decide to cancel a patch release, and include the patches in the
 > upcoming major release.
 
 > **Note**: Security releases are also "patch releases", but follow
 > a different procedure. Security releases are developed in a private
 > repository, released and tested under embargo before they become
 > publicly available.