热修复流程

概述

RAPIDS 热修复发布流程概述。

目标读者

开发者

项目负责人

运维人员

另请参阅

• 热修复版本控制
• 主要版本和次要版本

热修复

热修复（或补丁）发布不是预先计划的，用于解决当前版本中的关键问题。以下标准和流程旨在帮助确定什么是热修复。

标准

热修复是指影响大多数用户且没有合理变通方法的重大错误。

因此请考虑以下问题

• 这个错误是否重大？
  • 它是否产生不正确的结果？
  • 使用有效输入时是否存在编译或运行时错误？
  • 是否存在主要功能不正常？
• 它是否影响大多数用户？
  • 这个错误是否影响常见或主要功能？
  • 导致错误的输入是常见情况还是边缘情况？
  • 普通用户在正常、平均使用过程中会遇到这个错误吗？
• 是否有合理的变通方法？
  • 是否甚至存在变通方法？
  • 潜在的变通方法能否有效地传达给社区？
  • 普通用户会理解这个变通方法吗？
  • 一个变通方法需要多少步骤/代码修改？
  • 错误修复后，变通方法是否仍然有效？

另请考虑下一个版本计划发布的时间。如果冻结或发布日期在几天之内，请考虑等待并将热修复包含在下一个版本中。

流程

注意：以下流程使用这些版本作为示例

• 当前版本 M.A.X
• 下一个次要版本 M.B.0（其中 B=A+1）
• 下一个补丁版本 M.A.Y（其中 Y=X+1）

开发者

1. 热修复问题将分配给您
2. 从 branch-M.A 分支创建您的分支
3. 简洁地实现修复
4. 更改所需的最少代码量
5. 更新相关文档和单元测试
6. 可以接受实现一个快速修复并为更深入的解决方案开启一个新的问题
7. 完成后，创建一个针对 branch-M.A 的拉取请求
8. 通知项目负责人

项目负责人

1. 在分类处理期间，识别潜在的热修复
2. 确保满足热修复标准
3. 分配问题并跟踪其进度
4. 通知运维人员正在进行热修复工作
5. 收到拉取请求已创建的通知后，进行审查和批准。不要合并拉取请求。
6. 通知运维人员热修复拉取请求已准备好合并

运维人员

1. 收到项目负责人的通知后，审查拉取请求
2. 开始测试 conda 和容器的正确性和功能性
3. 审查文档以确保版本号（更新到 M.A.Y）和说明正确
4. 批准后，合并开发者针对 branch-M.A 的 PR
5. 从 branch-M.A 创建一个针对 main 的新 PR
6. 审查和批准后，合并针对 main 的 PR
7. 监控自动化工具的流程
8. 抽查交付物以确保正确性