Kubernetes Patch Release Schedule and Procedures

--- title: Patch Releases type: docs --- Schedule and team contact information for Kubernetes patch releases. For general information about Kubernetes release cycle, see the [release process description]. ## Cadence Our typical patch release cadence is monthly. It is commonly a bit faster (1 to 2 weeks) for the earliest patch releases after a 1.X minor release. Critical bug fixes may cause a more immediate release outside of the normal cadence. We also aim to not make releases during major holiday periods. ## Contact See the [Release Managers page][release-managers] for full contact details on the Patch Release Team. Please give us a business day to respond - we may be in a different timezone! In between releases the team is looking at incoming cherry pick requests on a weekly basis. The team will get in touch with submitters via GitHub PR, SIG channels in Slack, and direct messages in Slack and [email](mailto:release-managers-private@kubernetes.io) if there are questions on the PR. ## Cherry picks Please follow the [cherry pick process][cherry-picks]. Cherry picks must be merge-ready in GitHub with proper labels (e.g., `approved`, `lgtm`, `release-note`) and passing CI tests ahead of the cherry pick deadline. This is typically two days before the target release, but may be more. Earlier PR readiness is better, as we need time to get CI signal after merging your cherry picks ahead of the actual release. Cherry pick PRs which miss merge criteria will be carried over and tracked for the next patch release. ## Support Period In accordance with the [yearly support KEP][yearly-support], the Kubernetes Community will support active patch release series for a period of roughly fourteen (14) months. The first twelve months of this timeframe will be considered the standard period. Towards the end of the twelve month, the following will happen: - [Release Managers][release-managers] will cut a release - The patch release series will enter maintenance mode During the two-month maintenance mode period, Release Managers may cut additional maintenance releases to resolve: - [Vulnerabilities](/docs/reference/issues-security/official-cve-feed/) that have an assigned CVE ID (under the advisement of the Security Response Committee) - dependency issues (including base image updates) - critical core component issues At the end of the two-month maintenance mode period, the patch release series will be considered EOL (end of life) and cherry picks to the associated branch are to be closed soon afterwards. Note that the 28th of the month was chosen for maintenance mode and EOL target dates for simplicity (every month has it). ## Upcoming Monthly Releases Timelines may vary with the severity of bug fixes, but for easier planning we will target the following monthly release points. Unplanned, critical releases may also occur in between these. {{< upcoming-releases >}} ## Detailed Release History for Active Branches {{< release-branches >}} ## Non-Active Branch history These releases are no longer supported. {{< eol-releases >}}

This document describes the Kubernetes patch release process, including the typical monthly cadence, team contact information, cherry-pick requirements, and support period. It details how to submit cherry-pick requests, the criteria for merging them, and the support window for each release series, including a maintenance mode for critical fixes before EOL.