Kubernetes 发布周期

针对发布里程碑的特性增强、Issue 和 PR

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

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

  • 特性增强、问题和拉取请求的所有者
  • SIG 负责人
  • 发布团队

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

作为特性增强、问题或拉取请求 (PR) 的所有者，你有责任确保满足里程碑发布要求。 如果需要更新，自动化和发布团队将与你联系，但无响应可能会导致你的工作从里程碑中删除。 当目标里程碑是先前版本时，还存在其他要求（请参阅 Cherry Pick 流程了解更多信息）。

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 分支现在是通过 Cherry Pick，由发布管理员批准。

过去，针对里程碑的拉取请求需要打开相关的 GitHub 问题，但现在情况不再如此。 特性或特性增强实际上是 GitHub 问题或导致后续 PR 的 KEPs。

一般的打标签过程应该在不同工件类型之间保持一致。

定义

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

  • 发布小组：每个 Kubernetes 版本都有一个团队来执行这里所描述的项目管理任务。

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

  • Y 天：指工作日

  • 增强：参见“我的改进是特性增强吗？”

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

  • 异常请求： 请求延长特性增强的截止日期的过程

  • 代码冻结： 最终发布日期前约 4 周的时间，在此期间，仅将关键错误修复合并到发布中。

  • 修剪： 如果特性增强未完全实现或被认为不稳定，则在此过程中从发布里程碑中删除它。

  • 发布里程碑：语义版本字符串或 GitHub 里程碑 指的是发布 主.次 vX.Y 版本。

    另请参阅发布版本控制。

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

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

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

发布周期

Image of one Kubernetes release cycle

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 挑选回发布分支。发布版本是从发布分支构建的。

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

Image of Kubernetes release lifecycle spanning three releases

从里程碑中删除项目

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

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

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

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

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

如果需要采取其他措施，发布团队将通过以下渠道尝试进行人与人之间的对话：

  • 在 GitHub 中发表评论，根据问题类型提及 SIG 团队和 SIG 成员
  • 给 SIG 邮件列表发邮件
    • 使用来自社区 SIG 列表的群组电子邮件地址进行引导
    • 也可选择直接与 SIG 负责人或 SIG 其他成员联系
  • 向 SIG 的 Slack 频道发送消息
    • 在 Slack 频道 和 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 更积极地移出里程碑

Issue/PR 分类标签

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

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

  • kind/api-change：添加、删除或更改 API
  • kind/bug：修复了一个新发现的错误
  • kind/cleanup：添加测试、重构、修复旧错误
  • kind/design：与设计相关
  • kind/documentation：添加文档
  • kind/failing-test：CI 测试用例一直失败
  • kind/feature：新功能
  • kind/flake：CI 测试用例显示间歇性故障
最后修改 December 15, 2024 at 6:24 PM PST: Merge pull request #49087 from Arhell/es-link (2c4497f)