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;
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:
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.
When the criteria for moving forward with a patch release are met, the release manager will decide on the exact content of the release.
Any code delivered as part of a patch release should make life easier for a significant amount of users with zero chance of degrading anybody's experience. A good rule of thumb for that is to limit cherry-picking to small patches, which fix well-understood issues, and which come with verifiable tests.