Kubernetes 发布周期

针对发布里程碑的增强、问题和 PR

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

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

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

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

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

作为增强、问题或拉取请求（PR）的所有者，您有责任确保满足发布里程碑要求。如果需要更新，自动化和发布团队将与您联系，但 inaction 可能会导致您的工作从里程碑中移除。当目标里程碑是之前的发布时，存在额外的要求（有关更多信息，请参阅cherry pick 流程）。

TL;DR

如果您的 PR 要被合并，它需要以下必需的标签和里程碑，此处由 Prow /commands 表示，它们将用于添加这些标签

正常开发（第 1-11 周）

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

代码冻结（第 12-14 周）

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

发布后（第 14 周及以后）

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

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

合并到 1.y 分支现在通过 cherry pick，由发布经理批准。

过去，里程碑目标的拉取请求需要有一个相关的 GitHub issue，但现在不再是这样。功能或增强实际上是 GitHub issues 或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 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 不再需要打开的 issue，但打开的 issue 和相关的 PR 应该有同步的标签。例如，如果一个高优先级 bug issue 的相关 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 类型标签

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

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

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