168 lines
6.0 KiB
Markdown
168 lines
6.0 KiB
Markdown
---
|
||
title: 补丁版本
|
||
type: docs
|
||
---
|
||
<!--
|
||
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].
|
||
-->
|
||
Kubernetes 补丁版本的发布时间表和团队联系信息。
|
||
|
||
有关 Kubernetes 发布周期的常规信息，请参阅[发布流程说明](/zh-cn/releases/release)。
|
||
|
||
<!--
|
||
## 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.
|
||
-->
|
||
## 节奏 {#cadence}
|
||
|
||
我们的补丁发布节奏通常是每月一次。
|
||
在 1.X 次要版本之后，最早的补丁版本通常要快一些（提前 1 到 2 周）。
|
||
严重错误修复可能会导致超出正常节奏而更快速的发布。
|
||
我们尽量避免在重要的节假日期间发布。
|
||
|
||
<!--
|
||
## 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.
|
||
-->
|
||
## 联系方式 {#contact}
|
||
|
||
有关补丁发布团队（Patch Release Team）的完整联系方式，
|
||
请参阅[发布管理员页面](/zh-cn/releases/release-managers)。
|
||
|
||
请给我们一个工作日回复，因为我们可能在不同的时区！
|
||
|
||
在两次发布之间，团队每周都会查看收到的 cherry pick 请求。
|
||
如果对 PR 有任何问题，团队将通过 GitHub PR、Slack 中的 SIG 频道以及 Slack 中的直接消息和
|
||
[Email](mailto:release-managers-private@kubernetes.io) 与提交者取得联系。
|
||
|
||
<!--
|
||
## 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.
|
||
-->
|
||
## Cherry Pick
|
||
|
||
请遵循 [Cherry Pick 流程](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md)。
|
||
|
||
Cherry Pick 必须在 GitHub 中准备好合并，带有适当的标签（例如 `approved`、`lgtm`、`release-note`），
|
||
并在 Cherry Pick 截止日期之前通过 CI 测试。这通常是目标发布前两天，但可能更早。
|
||
PR 越早准备好越好，因为在实际发布之前，合并了你的 Cherry Pick 后，我们需要时间来获取 CI 信号。
|
||
|
||
不符合合并标准的 Cherry Pick PR 将被带入下一个补丁版本中跟踪。
|
||
|
||
<!--
|
||
## 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
|
||
-->
|
||
## 支持周期 {#support-period}
|
||
|
||
根据[年度支持 KEP](https://git.k8s.io/enhancements/keps/sig-release/1498-kubernetes-yearly-support-period/README.md)
|
||
约定，Kubernetes 社区将在大约 14 个月的时间内支持活跃的补丁发布系列。
|
||
|
||
此时间范围的前 12 个月将被视为标准周期。
|
||
|
||
在 12 个月后，将发生以下事情：
|
||
|
||
- [发布管理员](/zh-cn/releases/release-managers)将删除一个版本
|
||
- 补丁发布系列将进入维护模式
|
||
|
||
<!--
|
||
During the two-month maintenance mode period, Release Managers may cut
|
||
additional maintenance releases to resolve:
|
||
|
||
- CVEs (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).
|
||
-->
|
||
在两个月的维护模式期间，发布管理员可能会删减额外的维护版本以解决：
|
||
|
||
- CVE（在安全响应委员会的建议下）
|
||
- 依赖问题（包括基础镜像更新）
|
||
- 关键核心组件问题
|
||
|
||
在两个月的维护模式期结束时，补丁发布系列将被视为 EOL（生命周期结束），相关分支的 Cherry Pick 将很快关闭。
|
||
|
||
请注意，为简单起见，选择每月 28 日作为维护模式和 EOL 目标日期（每个月都有）。
|
||
|
||
<!--
|
||
## 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-monthly-releases}
|
||
|
||
时间表可能会因错误修复的严重程度而有所不同，但为了便于规划，我们每月将按照以下时间点进行发布。
|
||
中间可能会发布一些计划外的关键版本。
|
||
|
||
{{< upcoming-releases >}}
|
||
|
||
<!--
|
||
## Detailed Release History for Active Branches
|
||
-->
|
||
## 活动分支的详细发布历史 {#detailed-release-history-for-active-branches}
|
||
|
||
{{< release-branches >}}
|
||
|
||
<!--
|
||
## Non-Active Branch history
|
||
|
||
These releases are no longer supported.
|
||
-->
|
||
## 非活动分支历史 {#non-active-branch-history}
|
||
|
||
不再支持这些版本。
|
||
|
||
{{< eol-releases >}}
|