RAPIDS 文档

本站点使用 Just the Docs，一个基于 Jekyll 的文档主题。

Search

发布流程

概览

RAPIDS 主要和次要版本发布流程摘要。

目标受众

项目负责人

运维团队

另请参阅

Git 分支模型

RAPIDS 使用定制的 Git 分支模型，该模型由 git-flow 演变而来，旨在利用 GitHub 提供的工具并专注于发布驱动的开发。有关更多详细信息，请参阅我们的Git 分支方法指南。

项目迁移

对于使用其他分支/开发模型的 RAPIDS 项目，请继续使用该方法开发，直到下一个次要版本发布。给定版本 M.A.0（其中 M 是主版本，A 是次要版本），从包含最新次要版本的 main 分支创建开发分支 branch-M.B，其中 B=A+1。

从此刻起，您可以遵循 RAPIDS 团队使用的 Git 分支和发布模型。

主要和次要版本发布

主要和次要版本发布都遵循相同的步骤，差异很小。对于这两种发布类型，有三个关键日期需要提前确定：

  • 燃尽日期
  • 代码冻结日期
  • 发布日期

燃尽日期 总是比 代码冻结日期 早几天，而 代码冻结日期 又比 发布日期 早几天。这是为了确保有足够的时间完成活跃开发，并处理任何未知的 bug/问题。

热修复

热修复有其独立的流程，并此处进行了描述。

燃尽

燃尽是将所有计划在当前版本中解决的问题锁定，并将不在此版本中的问题移至下一版本的过程。此外，所有待处理的拉取请求都应在代码冻结日期前得到评审并力争合并。

时机

选择 燃尽日期 应遵循以下一般指南：

  • 选择的 燃尽日期 应至少比 代码冻结日期提前 3 个工作日
  • 咨询项目负责人，确保关键功能能在预期日期纳入发布版本
  • 立即将决定的 燃尽日期 传达给开发团队，确保他们能按时完成

燃尽过程在流程最后一天太平洋时间 (PT) 下午 11:59 结束。

流程

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

项目负责人

  1. 在 燃尽日期 开始时，提醒开发团队停止接受针对 M.B 发布版本的新问题（除非是关键 bug/问题）
  2. 努力合并针对 M.B 的现有拉取请求
  3. 将不再属于 M.B 发布版本的拉取请求或问题移至 M.C 项目看板或待办事项列表（对于待办事项列表，将问题从项目看板移除）

运维团队

  1. 在 燃尽日期 开始时，宣布 branch-M.B 的燃尽开始
  2. 将 branch-M.B 分叉到 branch-M.C 作为新的开发分支
  3. 创建发布版本 M.C 的项目看板
  4. 通知项目负责人流程已完成

另请参阅燃尽指南

代码冻结

代码冻结是发布版本进行彻底测试的过程。拉取请求不再被接受到开发分支中。对于热修复问题可能会有例外。燃尽阶段的所有拉取请求应在代码冻结开始前合并，或移至下一发布版本。

时机

选择 代码冻结日期 应遵循以下一般指南：

  • 选择的 代码冻结日期 应至少比 发布日期提前 3 个工作日
  • 立即将决定的 代码冻结日期 传达给开发团队，确保他们能按时完成

代码冻结在燃尽结束后的第二天太平洋时间 (PT) 凌晨 12:00 开始。

例如，如果燃尽从 2 月 3 日星期三持续到 2 月 9 日星期二，那么燃尽在 2 月 9 日太平洋时间 (PT) 下午 11:59 结束，代码冻结在 2 月 10 日太平洋时间 (PT) 凌晨 12:00 开始。

流程

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

通常，代码冻结流程在代码冻结第一天太平洋时间 (PT) 上午 10:00 左右进行。

项目负责人

  1. 在 cuDF 燃尽前至少两周通知运维团队任何新的发布制品（包、wheel、容器）
  2. 将任何针对 branch-M.B 的开放拉取请求改为针对 branch-M.C
  3. 等待运维团队确认分支切换
  4. 继续进行 M.C 的开发
  5. 如果发现 M.B 发布版本有任何问题，及时响应运维团队

运维团队

  1. 在 代码冻结日期 开始时，宣布 branch-M.B 的代码冻结开始
  2. 将项目的 GitHub 默认分支切换到 branch-M.C
  3. 创建 M.B 发布版本跟踪项目看板
  4. 通知项目负责人流程已完成

发布

时机

选择 发布日期 应遵循以下一般指南：

  • 选择的 发布日期 应至少比上一个 发布日期晚 3-4 周
  • 咨询项目负责人，确保关键功能能在预期日期纳入发布版本
  • 立即将决定的 发布日期 传达给开发团队，确保他们能按时完成

流程

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

项目负责人

  1. 在 发布日期 开始时，与开发人员合作关闭所有未解决的问题和 PR
  2. 协助运维团队测试和验证发布版本 M.B PR 中的文档
  3. 评审发布版本 M.B 以进行批准
  4. 协助运维团队在发布后抽查交付物

运维团队

  1. 在 发布日期 开始时，宣布 branch-M.B 的发布
  2. 从 branch-M.B 创建针对 main 的发布 PR
  3. 开始测试 conda、容器和 notebook 的正确性和功能性
  4. 与开发团队合作关闭未解决的 PR
  5. 评审文档，确保版本号和说明正确无误
  6. 邀请项目评审人员批准发布 PR
  7. 批准后合并发布 PR
  8. 监控自动化工具的流程
  9. 抽查交付物，确保正确性