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.yaml

version: "8.5.0"
type: "minor"          # major=重构, minor=新功能, patch=修复
target_date: "2025-06-30"

features:
  - name: "MoE Expert 动态负载均衡"
    repo: ops-transformer
    contact: "@ml-team/pager-duty"

  - name: "FP8 量化推理支持"
    repo: ops-nn
    dependency: "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.sh

rc_tag="v8.5.0-rc3"

# 测试矩阵：3 个平台 × 4 个模型 × 3 种 dtype
validate_rc() {
    local platforms=("ascend-910" "ascend-910b" "ascend-950pr")
    local models=("llama-7b" "llama-70b" "chatglm-6b" "qwen-14b")
    local dtypes=("fp16" "bf16" "fp8")

    for plat in "${platforms[@]}"; do
        for model in "${models[@]}"; do
            for dtype in "${dtypes[@]}"; do
                echo "Testing: $plat × $model × $dtype"
                run_integration_test --tag=$rc_tag \
                    --platform=$plat --model=$model --dtype=$dtype
            done
        done
    done
}

每次 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 上的所有 commit
git log --oneline --grep="fix.*hbm\|fix.*flash\|fix.*kv" main

# 2. Cherry-pick 到 release/8.0
git checkout release/8.0
git cherry-pick fix_hbm       # 第一个修复
# → 如果 cherry-pick 冲突：检查 8.0 的 driver 代码结构和 main 有差异
#   解冲突：对齐 main 的修复逻辑到 8.0 的代码上下文
git cherry-pick fix_flash     # 第二个修复
git cherry-pick fix_kv        # 第三个修复

# 3. 打补丁标签
git tag v8.0.3 -m "Fix: HBM leak + FlashAttention overflow + KV Cache fragmentation"
git push 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 图
git log --oneline --graph fix_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/2897

---

release-management 不像算子仓库有代码可以跑——它的产出是一组保护分支、一份发布计划、一个完整的 RC 测试矩阵和一个清晰的版本公告。版本管理跟写 kernel 完全是两种技能：写的代码越少的工具，对「覆盖所有边际情况」的要求反而越高。