Kubernetes 发布周期

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

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

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

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

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

有关工作流和交互的信息如下所述。

作为增强功能、问题或拉取请求（PR）的所有者，您有责任确保满足发布里程碑的要求。如果需要更新，自动化和发布团队会与您联系，但不采取任何措施可能会导致您的工作从里程碑中删除。当目标里程碑是之前的版本时，还存在其他要求（有关更多信息，请参阅cherry pick 过程）。

TL;DR

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

正常开发（第 1-11 周）

• /sig {名称}
• /kind {类型}
• /lgtm
• /approved

代码冻结（第 12-14 周）

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

发布后（第 14 周以后）

返回“正常开发”阶段的要求

• /sig {名称}
• /kind {类型}
• /lgtm
• /approved

现在通过cherry pick，由发布经理批准，将合并到 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 周。在此期间，只有关键错误修复才会接受到发布代码库中。

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

当代码库足够稳定时，主分支将重新开放以进行常规开发，并且下一发布里程碑的工作从那里开始。当前版本的任何剩余修改都会从主分支中 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 列表中引导使用 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 来说，不再强制要求必须有开放的 issue，但是开放的 issue 和关联的 PR 应该有同步的标签。例如，一个高优先级的 bug issue 如果其关联的 PR 只被标记为较低优先级，则该 PR 可能不会被合并。

PR 添加

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

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

其他必需的标签

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

SIG 所有者标签

SIG 所有者标签定义了如果里程碑 issue 进展缓慢或需要额外关注时，我们将上报的 SIG。如果在上报后没有更新，该 issue 可能会自动从里程碑中移除。

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

优先级标签

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

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

问题/PR 类型标签

issue 类型用于帮助识别随着时间的推移进入发布的变更类型。这可能使发布团队更好地了解在更快的发布节奏下我们会错过哪些类型的 issue。

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

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