发布计划

概述

RAPIDS 项目所使用的发布计划流程摘要。

目标受众

项目负责人

另请参阅

• 版本和标签
• 发布流程

计划流程

时间安排

注意：以下流程使用当前版本 M.A、下一版本 M.B 和未来版本 M.C（其中 B=A+1，C=B+1）作为示例。

发布计划分为两个阶段

1. 模糊计划 来自 问题分类，这是持续进行的。
2. 重点计划 当版本 M.B 被冻结时开始。

发布看板

RAPIDS 项目使用 GitHub 项目看板来跟踪发布，并带有从现有看板复制的自定义设置和自动化。

每个项目都有一个对应每个版本的发布看板。例如，v0.5 版本 看板跟踪 v0.5 版本的进度。发布看板在版本完成后关闭，并标记为 vM.A 版本，其中 M 和 A 是主要和次要版本号。

每个发布看板包含以下列

列	用途
问题 - 需要确定优先级	经过 问题分类 流程并且需要确定优先级的问题
问题 - P0	应优先处理的问题
问题 - P1	仅当所有 P0 问题都已完成或已分配时才应处理的问题
问题 - P2	仅当所有 P1 问题都已完成或已分配时才应处理的问题
PR - 进行中	新打开的 PR 和重新打开的 PR
PR - 需要评审	当等待评审者批准时，PR 会自动移动到此列
PR - 评审者已批准	当评审者批准时，PR 会自动移动到此列
完成	已关闭的问题和 PR 将自动移动到此列

重要提示：通过利用发布看板处理问题，项目负责人可以通过将问题放在相应的列中来安排问题，然后通过将问题从列顶部的最高优先级拖动和排序到底部的最低优先级来确定问题的优先级。我们还可以使用问题/PR 上的标签来过滤和确定工作的优先级。

使用发布看板

• 分配和确定工作优先级
  • 向左滚动以查看所有标记为 Issue-* 的列
  • 通过在列之间移动问题来重新确定 P0、P1、P2 中问题的优先级
  • 将列中的高优先级问题移到顶部；这促进了“优先处理最顶部事项”的开发
• 加快并完成工作
  • 向右滚动以查看所有标记为 PR-* 的列
  • 识别需要评审者、作者输入以及其他帮助的 PR

模糊计划

在 模糊计划 期间，问题在其各自的跟踪看板中进行分类和安排。这自然会从各个跟踪看板中创建一个问题池，供在 重点计划 期间在 未来版本 列下考虑。

重点计划

一旦 WIP 版本（即版本 M.B）的冻结发生，则版本 M.C 的计划将开始。

项目负责人

1. 评审当前 WIP 版本 M.B 中的所有问题，并找出将延期的问题。
2. 将无法在版本 M.B 中完成的问题移至 M.C 版本的发布看板。
3. 评审每个跟踪看板，并检查 未来版本 列中的所有问题。
4. 将确定属于 M.C 版本范围的问题添加到发布看板，并将该问题移至跟踪看板的 下一版本 列。
5. 结合项目负责人的意见，将 M.C 发布看板上的所有问题按优先级分类到 P0、P1 或 P2 列。
6. 在 P0、P1 或 P2 列内对问题进行排序，以向开发者传达优先级。
7. 在 M.B 版本发布后的第二天与团队进行评审，以获取反馈和意见，然后将其作为初步发布计划。