昇腾CANN release-management：版本发布流程和升级策略
community 仓库定义了谁决策，release-management 实现了怎么发布。CANN 的版本发布遵循语义化版本（SemVer）+ LTS 策略。每个版本从计划到上线，经过版本节奏定义 → 发行版集成 → 基础设施验证 → 发布公告，全套流程都有标准化模板。
版本节奏和发行策略
CANN 的两类版本：
| 版本类型 | 发布频率 | 支持周期 | 适用场景 |
|---|---|---|---|
| 正式版 (8.x) | 6-12个月 | 24个月 | 生产环境 |
| 补丁版 (8.x.y) | 每月 | 随正式版 | 安全修复/关键 bug |
正式版是受保护分支，补丁版是 cherry-pick 修复。补丁版只合入三类修复：安全漏洞、数据不一致 bug（算错结果）、HBM 泄漏。性能优化不进补丁版——在正式版之后的下一个版本里一起上。
LTS 策略：每两个正式版中选一个做 LTS（Long Term Support），对应选择是 8.0（LTS）和 8.5（非 LTS）。LTS 版的支持延长到 36 个月，非 LTS 版 24 个月。
一个版本发布的完整流程
CANN 的发布周期分五个阶段：
Plan → Develop → Freeze → RC → Release (2周) (12-20周) (2周) (4周) (1天)阶段 1：Plan（版本计划）
版本计划会定义该版本的关键交付：
# release/v8.5/plan.yamlversion:"8.5.0"type:"minor"# major=重构, minor=新功能, patch=修复target_date:"2025-06-30"features:-name:"MoE Expert 动态负载均衡"repo:ops-transformercontact:"@ml-team/pager-duty"-name:"FP8 量化推理支持"repo:ops-nndependency:"metadef v3.1"# 依赖其他仓的版本quality_goals:ut_coverage:">=85%"integration_test_pass_rate:"100%"risk_items:-"FP8 fused kernel 调度在不同 NPU 核数下行为不一致"mitigation:"提前两周进入 freeze"阶段 2：Develop（开发期）
各仓库按计划开发新功能。关键规则：
// release-management/scripts/branch_check.sh// 开发期中每个合入的 PR 必须通过分支检查// 分支规则保护关键分支//// main// ├──────────── main : 当前开发的主分支（下一个版本的代码）// ├── release/8.0 : 8.0 LTS 补丁分支（只允许 hotfix 合入）// ├── release/8.5 : 8.5 开发分支（feature 合入）// └── vendor/* : 华为内部预发布分支（不进社区）// 保护规则：// 1. release/* 分支：禁止 force push（保护版本历史）// 2. main 分支：CI 必须全绿（protect-base）// 3. PR 合入：至少两个 reviewer approve + CI 全绿阶段 3：Freeze（冻结期）
冻结期内只合入三类修复：
## Freeze 期合入规则 允许合入（三类）： 1. Fix: 修复 CT（准确率下降、结果错误、精度退化） 2. Fix: 修复功能问题（HBM 泄漏、SIGSEGV、算子 hang） 3. Doc: 文档修复（拼写、链接、示例代码） 禁止合入： - 任何新 feature（包括小的改进） - 任何性能优化（即使有 benchmark 证明） - 任何重构阶段 4：RC（候选发布）
Release Candidate 选定后，用自动化测试矩阵跑一遍：
#!/bin/bash# release-management/rc_validation.shrc_tag="v8.5.0-rc3"# 测试矩阵：3 个平台 × 4 个模型 × 3 种 dtypevalidate_rc(){localplatforms=("ascend-910""ascend-910b""ascend-950pr")localmodels=("llama-7b""llama-70b""chatglm-6b""qwen-14b")localdtypes=("fp16""bf16""fp8")forplatin"${platforms[@]}";doformodelin"${models[@]}";dofordtypein"${dtypes[@]}";doecho"Testing:$plat×$model×$dtype"run_integration_test--tag=$rc_tag\--platform=$plat--model=$model--dtype=$dtypedonedonedone}每次 RC 推送，触发这个矩阵测试。3×4×3 = 36 组用例，任何一组失败则冻结期延长。
阶段 5：Release（正式发布）
RC 通过后，推送正式 Release Tag 并发布公告：
## v8.5.0 发布公告 ### 版本信息 - 发布日期：2025-07-01 - Release分支：release/8.5 - 支持平台：Ascend 910/910B/950PR ### 新特性 - MoE Expert 动态负载均衡（ops-transformer） - FP8 量化推理支持（ops-nn） - 算子自动融合增强（graph-autofusion） ### 已知问题 & 解决方案 | 问题 | 影响 | 解决方案 | |------|------|---------| | FP8 在 batch < 4 时性能下降 | 小 batch 场景 | 用 FP16 替代 | | ascend-950pr × llama-70b 的 MoE AllGather 延迟异常 | 分布式推理 | 升级 hccl 到 v2.6 |攻陷一个补丁版本
补丁版本的实质是 cherry-pick 操作——从主分支选取防护修复到受保护的分支：
# 发布补丁 v8.0.3# v8.0.2 用户报告了三个关键 bug：# 1. HBM 泄漏（Driver）# 2. FlashAttention FP16 溢出（ops-transformer）# 3. KV Cache 碎片化（runtime）# 修复已合入 main，现在需要 cherry-pick 到 release/8.0# 1. 找到修复在 main 上的所有 commitgitlog--oneline--grep="fix.*hbm\|fix.*flash\|fix.*kv"main# 2. Cherry-pick 到 release/8.0gitcheckout release/8.0gitcherry-pick fix_hbm# 第一个修复# → 如果 cherry-pick 冲突：检查 8.0 的 driver 代码结构和 main 有差异# 解冲突：对齐 main 的修复逻辑到 8.0 的代码上下文gitcherry-pick fix_flash# 第二个修复gitcherry-pick fix_kv# 第三个修复# 3. 打补丁标签gittag v8.0.3-m"Fix: HBM leak + FlashAttention overflow + KV Cache fragmentation"gitpush origin v8.0.3踩坑一：Cherry-pick 丢失上下文
Cherry-pick 到旧分支时，修复代码的依赖变更可能不在旧分支上。修复在 main 上自动 pass，到了 release/8.0 上编译不过。
错误现象：修复依赖了 main 上一个重构后的辅助函数hbm_compact()。release/8.0 没有这个函数——因为重构是 8.5 才合入的。
正确做法：cherry-pick 前检查依赖变量的变更跨度。
# Cherry-pick 前检查 dep 图gitlog--oneline--graphfix_hbm..main# 如果 fix_hbm 和 release/8.0 之间有 50+ 个 commit# 且这些变更不在 release/8.0 上 → 必须手动解冲突，不能直接 cherry-pick# 手动解冲突 = 把修复逻辑改写为 8.0 的代码上下文# 不是强行合入 main 的代码踩坑二：RC 矩阵测试忘记 BF16
只有 fp16 和 fp8 的 RC 测试矩阵——上线后 BF16 用户切模型时遇到算子不兼容。
Quest：混沌社区默认 BF16 用的人少，但部分推理模型（特别是 Qwen 系列）的官方权重是 BF16 格式。
正确做法：矩阵里务必加上 BF16 测试列——对进行 dtypes 中强制要求至少 3 个。
踩坑三：版本公告的已知问题写了太轻
版本公告的「已知问题」部分只写了「偶发性能下降」，不写具体表现——用户上线后定位不到问题。
错误写法：
### 已知问题 - ascend-950pr 上存在偶发性能下降正确写法：
### 已知问题 - ascend-950pr 上 llama-70b MoE AllGather 延迟异常 * 表现：第 3-5 层的 AllGather 耗时从 2ms 增加到 15ms * 影响：分布式推理的 token/s 降低 12% * 根因：hccl < v2.6 在 950PR 上用 ring 而非 halving-doubling * 解决方案：升级 hccl 到 v2.6+ * 跟踪问题：github.com/cann/hccl/issues/2897release-management 不像算子仓库有代码可以跑——它的产出是一组保护分支、一份发布计划、一个完整的 RC 测试矩阵和一个清晰的版本公告。版本管理跟写 kernel 完全是两种技能：写的代码越少的工具，对「覆盖所有边际情况」的要求反而越高。