Kubernetes 发布周期

将增强特性、议题和 PR 定位到版本里程碑

本文档重点面向需要创建针对特定版本里程碑的增强特性、议题或拉取请求（PR）的 Kubernetes 开发者和贡献者。

• 太长不看
  • 常规开发（第 1-11 周）
  • 代码冻结（第 12-14 周）
  • 发布后（第 14 周及以后）
• 定义
• 版本周期
• 从里程碑中移除项
• 向里程碑添加项
  • 里程碑维护者
  • 新增特性
  • 新增议题
  • 新增 PR
• 其他必需标签
  • SIG 拥有者标签
  • 优先级标签
  • 议题/PR 类型标签

将增强特性、议题和拉取请求引导到 Kubernetes 版本的过程涉及多个干系人

• 增强特性、议题和拉取请求的拥有者
• SIG 领导层
• 版本发布团队

工作流和交互信息在下面描述。

作为增强特性、议题或拉取请求（PR）的拥有者，你有责任确保满足版本里程碑要求。如果需要更新，自动化工具和版本发布团队将与你联系，但不作为可能导致你的工作被从里程碑中移除。当目标里程碑是先前版本时，存在额外要求（有关更多信息，请参阅cherry pick（合入）过程）。

太长不看

如果你想让你的 PR 被合入，它需要以下必需的标签和里程碑，在此通过添加它们的 Prow /命令表示

常规开发（第 1-11 周）

• /sig {name}
• /kind {type}
• /lgtm
• /approved

代码冻结（第 12-14 周）

• /milestone {v1.y}
• /sig {name}
• /kind {bug, failing-test}
• /lgtm
• /approved

发布后（第 14 周及以后）

返回“常规开发”阶段要求

• /sig {name}
• /kind {type}
• /lgtm
• /approved

现在合入 1.y 分支通过 cherry pick（合入），由版本经理批准。

过去，针对里程碑的拉取请求要求打开相关的 GitHub 议题，但现在不再如此。特性或增强特性实际上是 GitHub 议题或KEPs，它们会产生后续的 PR。

标签添加的总体过程应在各种工件类型之间保持一致。

定义

• 议题拥有者：创建者、受让人以及将议题移至版本里程碑的用户

• 版本发布团队：每个 Kubernetes 版本都有一个团队负责执行此处描述的项目管理任务。

  与任何给定版本关联的团队的联系信息可在此处找到。

• Y 天：指工作日

• 增强特性：参见“我的东西是增强特性吗？”

• 增强特性冻结：KEPs 必须完成的截止日期，以便增强特性可以成为当前版本的一部分

• 例外申请：请求延长某个增强特性截止日期的过程

• 代码冻结：在最终发布日期前约 4 周的时间段内，期间只有关键的 bug 修复会被合入到版本中。

• 修剪：如果增强特性未完全实现或被认为不稳定，则将其从版本里程碑中移除的过程。

• 版本里程碑：语义版本字符串或GitHub 里程碑，指的是一个版本 MAJOR.MINOR vX.Y 版本。

  另见版本控制。

• 版本分支：为 vX.Y 里程碑创建的 Git 分支 release-X.Y。

  在 vX.Y-rc.0 版本发布时创建，并在发布后维护约 12 个月，期间发布 vX.Y.Z 补丁版本。

  注意：版本 1.19 及更新版本获得 1 年的补丁版本支持，版本 1.18 及更早版本获得 9 个月的补丁版本支持。

版本周期

Kubernetes 版本发布目前每年大约发生三次。

版本发布过程可被视为包含三个主要阶段：

• 增强特性定义
• 实现
• 稳定性维护

但实际上，这是一个开源且敏捷的项目，特性规划和实现随时都在进行。考虑到项目规模和全球分布的开发者基础，项目速度的关键在于不依赖于滞后的稳定性维护阶段，而是通过持续集成测试来确保项目始终稳定，这样可以标记出破坏性的单个提交。

随着全年持续进行的特性定义工作，一些项目会浮现出来并目标某个特定版本。增强特性冻结在版本周期开始后约 4 周启动。到此时，该版本所有预期的特性工作都已与版本发布团队的增强特性负责人一起，在合适的规划工件中定义完成。

增强特性冻结之后，跟踪 PR 和议题的里程碑很重要。里程碑内的项被用作完成版本的核对清单。对于议题，必须通过 SIG 的分诊正确应用里程碑，以便版本发布团队能够跟踪 bug 和增强特性（任何与增强特性相关的议题都需要设置里程碑）。

存在一些自动化机制帮助自动为 PR 分配里程碑。

该自动化机制目前适用于以下仓库

• kubernetes/enhancements
• kubernetes/kubernetes
• kubernetes/release
• kubernetes/sig-release
• kubernetes/test-infra

在创建时，针对 master 分支的 PR 需要人工提示 PR 想要目标哪个里程碑。合入后，针对 master 分支的 PR 会自动应用里程碑，从那时起，对该 PR 里程碑的人工管理就不那么必要了。针对版本分支的 PR，在 PR 创建时就会自动应用里程碑，因此完全不需要对里程碑进行人工管理。

任何其他应由版本发布团队跟踪的、不属于上述自动化范围的努力，都应应用里程碑。

实现和 bug 修复在整个周期中持续进行，但最终会在代码冻结期达到高峰。

代码冻结在大约第 12 周开始，并持续约 2 周。在此期间，只有关键 bug 修复会被接受并合入到版本代码库。

代码冻结之后、版本发布之前大约有两周时间，在此期间，所有剩余的关键议题必须在发布前解决。这也为文档定稿留出了时间。

当代码库足够稳定时，master 分支会重新开放进行常规开发，下一个版本里程碑的工作在那里开始。当前版本剩余的修改会从 master 分支通过 cherry pick（合入）回版本分支。版本是从版本分支构建的。

每个版本都是更广泛的 Kubernetes 生命周期的一部分

从里程碑中移除项

在深入探讨向里程碑添加项的过程之前，请注意

版本发布团队的成员如果他们或负责的 SIG 认为该议题实际上并未阻塞版本发布，且不太可能及时解决，则可以从里程碑中移除议题。

版本发布团队的成员可以出于以下任何或类似原因从里程碑中移除 PR

• PR 可能导致不稳定，且并非解决阻塞性议题所必需
• PR 是新的、迟到的特性 PR，并且未经过增强特性过程或例外申请过程
• 没有负责的 SIG 愿意对该 PR 负责并解决与之相关的任何后续议题
• PR 未正确添加标签
• PR 的工作已明显暂停，且交付日期不确定或已延迟

虽然版本发布团队的成员会协助标签添加和联系 SIG，但提交者有责任对 PR 进行分类，并获得相关 SIG 的支持，以保证由 PR 引起的任何问题能够迅速解决。

如果需要采取额外行动，版本发布团队将尝试通过以下渠道进行人对人的升级沟通

• 在 GitHub 评论中根据议题类型选择性地提及 SIG 团队和 SIG 成员
• 发送邮件到 SIG 邮件列表
  • 使用来自社区 SIG 列表的群组邮箱地址进行引导
  • 可选地，也可以直接@提及 SIG 领导层或其他 SIG 成员
• 在 SIG 的 Slack 频道中发送消息
  • 使用来自社区 SIG 列表的 Slack 频道和 SIG 领导层信息进行引导
  • 可选地，直接使用@提及 SIG 领导层或其他成员的句柄

向里程碑添加项

里程碑维护者

milestone-maintainers GitHub 团队的成员负责在 GitHub 工件上指定版本里程碑。

该组由 SIG Release 维护，并由各个 SIG 的领导层代表组成。

代码冻结后，严禁向拉取请求添加正在进行中的版本里程碑，因为这会损害版本的稳定性。在进行此类更改之前，必须获得版本发布团队负责人和荣退顾问的批准。

新增特性

特性规划和定义目前有多种形式，但一个典型例子可能是在 KEP 中描述的一项大型工作，并在 GitHub 中包含相关的任务议题。当计划达到可实施状态且工作正在进行时，该增强特性或其部分将被指定用于即将到来的里程碑，通过创建 GitHub 议题并使用 Prow "/milestone" 命令进行标记来实现。

在版本周期的前约 4 周内，版本发布团队的增强特性负责人将通过 GitHub、Slack 和 SIG 会议与 SIG 和特性拥有者互动，收集所有必需的规划工件。

如果你有一个增强特性想要目标一个即将到来的版本里程碑，请与你所属 SIG 的领导层以及该版本的增强特性负责人开始对话。

新增议题

议题通过 Prow "/milestone" 命令被标记为目标某个里程碑。

版本发布团队的Bug 分诊负责人以及整个社区关注新进议题并对其进行分诊，如贡献者指南中关于议题分诊的部分所述。

用里程碑标记议题为社区提供了更好的可见性，关于何时观察到某个议题以及社区认为必须在何时解决该议题。在代码冻结期间，必须设置里程碑才能合入 PR。

PR 不再需要关联已打开的议题，但已打开的议题和关联的 PR 应具有同步的标签。例如，一个高优先级的 bug 议题，如果其关联的 PR 只被标记为较低优先级，则可能不会被合入。

新增 PR

PR 通过 Prow "/milestone" 命令被标记为目标某个里程碑。

如上所述，这是在代码冻结期间的一个阻塞性要求。

其他必需标签

以下是标签列表及其用法和目的。

SIG 拥有者标签

SIG 拥有者标签定义了在里程碑议题停滞不前或需要额外关注时，我们将升级给哪个 SIG。如果升级后仍无进展，该议题可能会自动从里程碑中移除。

这些标签使用 Prow "/sig" 命令添加。例如，要添加表示 SIG Storage 负责的标签，请评论 /sig storage。

优先级标签

优先级标签用于确定在将议题移出版本里程碑之前的升级路径。它们还用于确定版本是否应被阻塞直到该议题解决。

• priority/critical-urgent：永不自动移出版本里程碑；通过所有可用渠道持续升级给贡献者和 SIG。
  • 被视为阻塞版本发布的议题
  • 在代码冻结期间要求议题拥有者每日更新
  • 如果在 minor 版本发布后才发现，则需要发布补丁版本
• priority/important-soon：升级给议题拥有者和 SIG 拥有者；在几次升级尝试失败后移出里程碑。
  • 不被视为阻塞版本发布的议题
  • 不需要发布补丁版本
  • 在代码冻结后经过 4 天宽限期会自动移出版本里程碑
• priority/important-longterm：升级给议题拥有者；尝试 1 次后移出里程碑。
  • 甚至比 priority/important-soon 更不紧急/不关键
  • 比 priority/important-soon 更积极地移出里程碑

议题/PR 类型标签

议题类型用于帮助识别随着时间推移进入版本的更改类型。这可能让版本发布团队更好地理解，如果发布节奏更快，我们会错过哪些类型的议题。

对于目标版本的议题，包括拉取请求，必须设置以下议题类型标签之一

• kind/api-change：添加、移除或更改 API
• kind/bug：修复新发现的 bug。
• kind/cleanup：添加测试、重构、修复旧 bug。
• kind/design：与设计相关
• kind/documentation：添加文档
• kind/failing-test：CI 测试用例持续失败。
• kind/feature：新功能。
• kind/flake：CI 测试用例间歇性失败。