昇腾CANN release-management：版本发布流程和升级策略

community 仓库定义了谁决策release-management 实现了怎么发布。CANN 的版本发布遵循语义化版本SemVer LTS 策略。每个版本从计划到上线经过版本节奏定义 → 发行版集成 → 基础设施验证 → 发布公告全套流程都有标准化模板。版本节奏和发行策略CANN 的两类版本版本类型发布频率支持周期适用场景正式版 (8.x)6-12个月24个月生产环境补丁版 (8.x.y)每月随正式版安全修复/关键 bug正式版是受保护分支补丁版是 cherry-pick 修复。补丁版只合入三类修复安全漏洞、数据不一致 bug算错结果、HBM 泄漏。性能优化不进补丁版——在正式版之后的下一个版本里一起上。LTS 策略每两个正式版中选一个做 LTSLong Term Support对应选择是 8.0LTS和 8.5非 LTS。LTS 版的支持延长到 36 个月非 LTS 版 24 个月。一个版本发布的完整流程CANN 的发布周期分五个阶段Plan → Develop → Freeze → RC → Release (2周) (12-20周) (2周) (4周) (1天)阶段 1Plan版本计划版本计划会定义该版本的关键交付# release/v8.5/plan.yamlversion:8.5.0type:minor# major重构, minor新功能, patch修复target_date:2025-06-30features:-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阶段 2Develop开发期各仓库按计划开发新功能。关键规则// 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 全绿阶段 3Freeze冻结期冻结期内只合入三类修复## Freeze 期合入规则 允许合入三类 1. Fix: 修复 CT准确率下降、结果错误、精度退化 2. Fix: 修复功能问题HBM 泄漏、SIGSEGV、算子 hang 3. Doc: 文档修复拼写、链接、示例代码 禁止合入 - 任何新 feature包括小的改进 - 任何性能优化即使有 benchmark 证明 - 任何重构阶段 4RC候选发布Release Candidate 选定后用自动化测试矩阵跑一遍#!/bin/bash# release-management/rc_validation.shrc_tagv8.5.0-rc3# 测试矩阵3 个平台 × 4 个模型 × 3 种 dtypevalidate_rc(){localplatforms(ascend-910ascend-910bascend-950pr)localmodels(llama-7bllama-70bchatglm-6bqwen-14b)localdtypes(fp16bf16fp8)forplatin${platforms[]};doformodelin${models[]};dofordtypein${dtypes[]};doechoTesting:$plat×$model×$dtyperun_integration_test--tag$rc_tag\--platform$plat--model$model--dtype$dtypedonedonedone}每次 RC 推送触发这个矩阵测试。3×4×3 36 组用例任何一组失败则冻结期延长。阶段 5Release正式发布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--grepfix.*hbm\|fix.*flash\|fix.*kvmain# 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-mFix: HBM leak FlashAttention overflow KV Cache fragmentationgitpush 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 完全是两种技能写的代码越少的工具对「覆盖所有边际情况」的要求反而越高。