Document process for patch-releases

This documents the procedures around creating patch-releases.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

project/PATCH-RELEASES.md

@@ -0,0 +1,53 @@
+# 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.