Kubernetes 版本周期

将增强功能、问题和 PR 定向到发布里程碑

本文档面向需要创建针对特定发布里程碑的增强功能、问题或拉取请求的 Kubernetes 开发人员和贡献者。

• TL;DR
  • 正常开发（第 1-11 周）
  • 代码冻结（第 12-14 周）
  • 发布后（第 14 周以上）
• 定义
• 发布周期
• 从里程碑中移除项目
• 向里程碑添加项目
  • 里程碑维护者
  • 功能添加
  • 问题添加
  • PR 添加
• 其他必需的标签
  • SIG 所有者标签
  • 优先级标签
  • 问题/PR 类型标签

将增强功能、问题和拉取请求引入 Kubernetes 版本的过程涉及多个利益相关者

• 增强功能、问题和拉取请求的所有者
• SIG 领导层
• 发布团队

下面介绍有关工作流程和交互的信息。

作为增强功能、问题或拉取请求 (PR) 的所有者，您有责任确保满足发布里程碑的要求。如果需要更新，自动化和发布团队将与您联系，但不采取行动可能会导致您的工作从里程碑中移除。当目标里程碑是先前版本时，存在其他要求（有关更多信息，请参阅挑选提交流程）。

TL;DR

如果您希望您的 PR 被合并，则需要以下必需的标签和里程碑，此处由添加它们所需的 Prow /commands 表示

正常开发（第 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 分支是通过挑选提交完成的，并由版本管理员批准。

过去，要求与里程碑相关的拉取请求必须打开关联的 GitHub 问题，但现在不再是这样了。功能或增强功能实际上是 GitHub 问题或KEP，它们会导致后续的 PR。

一般标签流程应在所有工件类型中保持一致。

定义

• 问题所有者：创建者、受让人和将问题移至发布里程碑的用户

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

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

• Y 天：指工作日

• 增强功能：请参阅“我的东西是增强功能吗？”

• 增强功能冻结：KEP 必须完成的截止日期，以便增强功能成为当前版本的一部分

• 例外请求：请求延长特定增强功能截止日期的过程

• 代码冻结：最终发布日期前约 4 周的时间段，在此期间，只有关键错误修复程序才会合并到发布代码库中。

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

• 发布里程碑：语义版本字符串或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 的分类正确应用里程碑，以便发布团队可以跟踪错误和增强功能（任何与增强功能相关的问题都需要一个里程碑）。

有一些自动化可以帮助自动将里程碑分配给 PR。

此自动化当前适用于以下存储库

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

在创建时，针对 master 分支的 PR 需要人工提示他们希望 PR 针对哪个里程碑。合并后，针对 master 分支的 PR 会自动应用里程碑，因此从那时起，人工管理该 PR 的里程碑就不那么必要了。在针对发布分支的 PR 上，在创建 PR 时会自动应用里程碑，因此永远不需要人工管理里程碑。

任何其他应该由发布团队跟踪但不属于该自动化范围的工作都应该应用里程碑。

实施和错误修复在整个周期中都在进行，但最终会在代码冻结期达到顶峰。

代码冻结 从第 12 周开始，持续约 2 周。在此期间，只有关键错误修复程序才会被接受到发布代码库中。

在代码冻结之后和发布之前大约有两周时间，在此期间，所有剩余的关键问题都必须在发布之前解决。这也为文档的最终确定提供了时间。

当代码库足够稳定时，master 分支将重新打开以进行一般开发，并开始为下一个发布里程碑开展工作。当前版本的所有剩余修改都将从 master 分支挑选提交回发布分支。该版本是从发布分支构建的。

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

从里程碑中移除项目

在深入了解将项目添加到里程碑的过程之前，请注意

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

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

• PR 可能会破坏稳定性，并且不需要解决阻塞问题
• PR 是一个新的、迟到的功能 PR，并且尚未经过增强流程或例外流程
• 没有负责任的 SIG 愿意接管 PR 并解决任何后续问题
• PR 未正确标记
• PR 上的工作明显停止，交付日期不确定或延迟

虽然发布团队的成员将帮助标记和联系 SIG，但提交者有责任对 PR 进行分类，并获得相关 SIG 的支持，以确保由 PR 引起的任何损坏都能得到快速解决。

如果需要采取其他行动，发布团队将尝试通过以下渠道进行人工升级

• 在 GitHub 中发表评论，提及 SIG 团队和 SIG 成员，以适应问题类型
• 向 SIG 邮件列表发送电子邮件
  • 使用社区 SIG 列表中的组电子邮件地址引导
  • 可以选择性地直接联系 SIG 领导层或其他 SIG 成员
• 向 SIG 的 Slack 频道发送消息
  • 使用社区 SIG 列表中的 slackchannel 和 SIG 领导层引导
  • 可以选择性地直接“@”提及 SIG 领导层或其他人的句柄

向里程碑添加项目

里程碑维护者

milestone-maintainers GitHub 团队的成员被赋予在 GitHub 工件上指定发布里程碑的责任。

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

功能添加

功能规划和定义有多种形式，但一个典型的例子可能是KEP中描述的一项大型工作，以及 GitHub 中相关的任务问题。当计划达到可实施状态并且工作正在进行中时，通过创建 GitHub 问题并使用 Prow“/milestone”命令标记它们，将增强功能或其部分内容定位到即将到来的里程碑。

在发布周期的前 4 周内，发布团队的增强功能负责人将通过 GitHub、Slack 和 SIG 会议与 SIG 和功能所有者互动，以捕获所有必需的计划工件。

如果您有想要在即将发布的版本里程碑中实现的增强功能，请先与您的 SIG 领导层以及该版本的增强功能负责人进行沟通。

问题添加

问题通过 Prow "/milestone" 命令标记为针对某个里程碑。

发布团队的错误分类负责人和整个社区会关注传入的问题并对其进行分类，如贡献者指南中关于问题分类的部分所述。

使用里程碑标记问题可以让社区更好地了解问题的发现时间以及社区认为必须解决问题的时间。在代码冻结期间，必须设置里程碑才能合并 PR。

PR 不再需要开放的问题，但开放的问题和相关的 PR 应具有同步的标签。例如，如果高优先级的错误问题关联的 PR 仅标记为较低优先级，则该 PR 可能不会被合并。

PR 添加

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

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

其他必需的标签

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

SIG 所有者标签

SIG 所有者标签定义了如果里程碑问题停滞不前或需要额外关注时，我们将升级到的 SIG。如果升级后没有更新，则该问题可能会自动从里程碑中移除。

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

优先级标签

优先级标签用于确定在将问题移出发布里程碑之前的升级路径。它们还用于确定是否应阻止发布以解决问题。

• priority/critical-urgent：永远不会自动从发布里程碑中移出；通过所有可用渠道不断升级到贡献者和 SIG。
  • 被视为发布阻塞问题
  • 在代码冻结期间需要问题所有者每日更新
  • 如果在次要版本发布之前一直未被发现，则需要发布补丁
• priority/important-soon：升级到问题所有者和 SIG 所有者；在多次升级尝试失败后，从里程碑中移出。
  • 不被视为发布阻塞问题
  • 不需要发布补丁
  • 在 4 天的宽限期后，将在代码冻结时自动从发布里程碑中移出
• priority/important-longterm：升级到问题所有者；尝试 1 次后，从里程碑中移出。
  • 比 priority/important-soon 紧急程度/关键程度更低
  • 比 priority/important-soon 更积极地从里程碑中移出

问题/PR 类型标签

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

对于发布目标问题，包括拉取请求，必须设置以下问题类型标签之一

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