3.0 KiB
Building Kubernetes patch releases
This document describes the process for creating Kubernetes patch releases and communicating publishing status regarding known issues impacting the current release.
Process
After a Kubernetes minor release, patch releases are managed by the Kubenretes patch release manager. The patch release manager works with SIGs to coordinate merging cherrypicks into the release branch, then cutting and publishing a new patch release.
Communicating fixes to the community
The canonical source of issues in a patch release will be communicated through GitHub issues.
To make it easy for the community to understand the status of each patch release, GitHub issues must follow a consistent format and contain basic information about the issue.
GitHub issues targeted at patch releases must contain the following items:
Priority label
The priority label describes the urgency and severity of the issue.
priority/critical-urgent: the issue is severe enough that it requires an immediate patch release (storage or network issues that can cause data corruption or outages for instance)priority/important-soon: the issue should be fixed in a patch does not need to be fixed immediately
Sig label
SIG labels should be applied for all SIGs involved in the issue / resolution.
sig/clisig/node
Summary template
The issue description should be kept up-to-date by the issue owner through out the resolution process. Items discovered as part of triage should be reflected in the issue description.
While much of this information may exist as discussion comments on the issue, providing the information in an easily understandable format and location makes it much easier to quickly understand the state of upcoming patch release.
The template will start with a section describing which releases the issue was introduced and resolved in. The format will be machine parsable so that bots can apply labels and generate reports using the information in the issue.
```release
introduced-in=vX.Y.Z
```
```release
resolved-in=vX.Y.Z
resolved-in=vX.Y+1.Z
```
The rest of the template is as follows:
## Symptoms
What users are experiencing
## Root cause
The technical cause of the symptoms including the list of components / binaries.
e.g.
Binaries:
- kubectl
Kubectl was incorrectly calculating the patch for apply. When diffing foo...
## Impact
Why this is important enough to warrant a patch vs waiting until the next minor release
## Resolution
How the issue will be (was) fixed
## PRs
- #23456
Communicating security fixes to the community
Due to the sensitive nature of security fixes, their details maybe omitted from the GitHub issue and simply state that the owner is working with the product security team on a resolution.