Kubernetes 版本发布周期

将增强功能、问题和 PR 定位到版本里程碑

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

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

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

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

以下描述了工作流程和交互的信息。

作为增强功能、问题或拉取请求 (PR) 的所有者，您有责任确保满足版本发布里程碑的要求。自动化和发布团队会与您联系，告知您是否需要更新，但如果未采取行动，您的工作可能会从里程碑中删除。当目标里程碑是先前版本时，将存在其他要求（有关更多信息，请参阅 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 问题打开，但现在不再需要。功能或增强功能实际上是 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 的分类正确应用，以便 发布团队 可以跟踪错误和增强功能（任何与增强功能相关的 issue 都需要里程碑）。

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

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

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

在创建时，针对 master 分支的 PR 需要人工提示他们希望 PR 针对哪个里程碑。针对 master 分支的 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 列表 中获取的 Slack 通道和 SIG 领导层引导。
  • 可以选择直接“@”提及 SIG 领导层或其他成员。

向里程碑添加项目

里程碑维护者

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

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

功能添加

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

在版本发布周期的前 4 周左右，发布团队的增强功能负责人将通过 GitHub、Slack 和 SIG 会议与 SIG 和功能所有者进行互动，以捕获所有必要的规划工件。

如果您要将增强功能作为即将到来的版本发布里程碑的目标，请与您的 SIG 领导层和该版本发布的增强功能负责人开始对话。

问题添加

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

发布团队的 错误分类负责人 和整个社区会监视传入的问题，并根据贡献者指南中关于 问题分类 的部分进行分类。

使用里程碑标记问题可以提高社区对问题何时被观察到以及社区认为必须在何时解决问题的可见性。在 代码冻结 期间，必须设置里程碑才能合并 PR。

PR 不再需要开放 issue，但开放 issue 和相关的 PR 应具有同步标签。例如，如果相关 PR 仅标记为低优先级，则高优先级 bug issue 可能不会合并其相关 PR。

PR 添加

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

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

其他必需标签

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

SIG 所有者标签

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

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

优先级标签

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

• priority/critical-urgent：从不自动移出发布里程碑；通过所有可用渠道持续升级到贡献者和 SIG。
  • 被视为发布阻塞问题
  • 在 代码冻结 期间需要 issue 拥有者每天更新
  • 如果遗漏到次要发布之后才发现，将需要补丁发布
• priority/important-soon：升级到 issue 拥有者和 SIG 拥有者；在多次升级尝试失败后，将移出里程碑。
  • 不被视为发布阻塞问题
  • 不需要补丁发布
  • 在代码冻结后，将在 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 测试用例显示间歇性故障。