☰
CANN 9.1.0 发布计划解析:从特性收集到正式发布的全流程版本管理
2026/10/14 7:18:44 网站建设 项目流程
  • 文档
  • CANN

【免费下载链接】release-management

CANN版本发布管理仓库

项目地址:https://gitcode.com/cann/release-management
点击查看免费下载

CANN(Compute Architecture for Neural Networks)版本发布管理仓库通过统一的"发布计划(release-plan)+发布说明(release-notes)"文档体系,对每个版本的研发节奏、特性清单与最终交付内容进行管控。本文以 9.1.0 发布计划 为骨架,逐阶段解读 CANN 9.1.0 从特性收集到正式发布的时间线安排、特性状态机定义,并结合仓库中的 Beta 版本计划与 9.1.0 版本说明,展示一条发布计划如何落地为实际版本交付内容,帮助读者掌握该仓库的版本管理规范与检索方式。

一、发布计划文档在仓库中的定位

仓库根目录的 README.md 明确了该仓库的职责:定义 CANN 版本发布管理方案,统一版本管控规范,明确版本发布的全流程步骤、版本号定义、变更记录要求与协作规则。仓库按版本号分目录组织,以 9.1.0 为例,目录内包含两份核心文档:

文档职责
release-plan.md版本发布计划与时间表,记录该版本的关键里程碑与特性清单
release-notes.md版本说明,详细描述功能更新、已修复问题、已知问题与兼容性配套

二者构成"先有计划、后有说明"的闭环:release-plan.md回答"什么时候做、做什么、谁来做",release-notes.md回答"最终交付了什么、怎么配套、有什么坑"。本文的主体是前者,后者作为特性落地的佐证。

二、CANN 9.1.0 发布时间线全景

9.1.0/release-plan.md的 Release plan 表格完整给出了 CANN 9.1.0 从 2026 年 3 月到 7 月的全部里程碑(原文表头为 "Stange name",应为 Stage name 之笔误,内容如下):

Stange nameBegin timeEnd time
Collect feature2026/03/012026/04/30
Develop2026/04/012026/06/24
Build2026/06/252026/06/25
Test round 12026/06/262026/07/03
Test round 22026/07/042026/07/11
Test round 32026/07/122026/07/19
QA report2026/07/202026/07/20
Release2026/07/302026/07/30

该时间表将整个发布周期划分为 8 个阶段,其中 Build、QA report、Release 均为单日里程碑,体现"固定节奏、关键节点"的管控思路。

三、阶段定义与节奏分析

3.1 各阶段职责

结合时间表与仓库其他版本的计划,各阶段含义如下:

  • Collect feature(特性收集,2026/03/01–04/30):收集需求与特性,评估是否纳入本版本。该阶段为期约两个月,是版本内容范围的输入端。
  • Develop(开发,2026/04/01–06/24):特性开发实现,跨度约 85 天。注意其起始时间(04/01)早于特性收集结束时间(04/30),说明特性收集与开发存在约一个月重叠期,即边收集边开发。
  • Build(构建,2026/06/25):单日完成版本构建出包,是开发与测试之间的交付节点。
  • Test round 1/2/3(测试轮次,2026/06/26–07/19):三轮测试,每轮 8 天,前后衔接无间隙。多轮测试设计用于逐轮收敛缺陷,保证发布质量。
  • QA report(QA 报告,2026/07/20):单日产出质量评估报告,是发布决策的依据。
  • Release(发布,2026/07/30):正式对外发布,与 QA 报告日之间留有约 10 天窗口,用于完成发布前准备。

3.2 与相邻版本计划的横向对比

仓库中其他版本的 release-plan 可以佐证该节奏的通用性:

版本周期特性收集开发构建发布
8.5.02025/10/15–2025/12/3010/15–10/3010/20–12/0512/06–12/0712/30
9.0.02026/01/01–2026/03/3001/01–01/3001/15–03/0803/0903/30
9.1.02026/03/01–2026/07/3003/01–04/3004/01–06/2406/2507/30
9.1.1(补丁)2026/08/06–2026/08/3108/06–08/1308/13–08/1808/18–08/2108/31
9.2.02026/06/01–2026/10/1506/01–06/3007/01–09/2409/2510/15

从对比可以看出:正式版本(如 8.5.0、9.0.0、9.1.0、9.2.0)的周期较长,且开发阶段普遍与特性收集重叠;补丁版本(如 9.0.1、9.1.1)周期显著缩短,开发仅数天,属于快速修复迭代。9.1.0 的开发周期(约 85 天)明显长于 8.5.0(约 47 天)和 9.0.0(约 53 天),从 9.1.0 版本说明 的新增特性规模看,该版本承载了大量算子、通信与图引擎能力增强,研发投入相应更大。

3.3 9.1.0 与 Beta 版本的里程碑衔接

9.1.0 的正式发布计划之外,仓库中还维护了三个 Beta 里程碑计划,形成"Beta 先行、GA 收口"的节奏:

版本发布日计划文档
9.1.0-beta.12026/05/109.1.0-beta.1/release-plan.md
9.1.0-beta.32026/06/249.1.0-beta.3/release-plan.md
9.1.0(GA)2026/07/309.1.0/release-plan.md

值得注意的是,9.1.0-beta.3 的发布日(06/24)恰好落在 9.1.0 正式版本开发阶段结束日(06/24)与 Build 日(06/25)之前,说明 Beta 版本是正式版本研发过程中的阶段性出包节点,其计划与 GA 计划在时间线上保持衔接。

四、Feature List 特性状态机

4.1 状态定义

9.1.0/release-plan.md的 Feture list(原文拼写,Feature list 之误)部分定义了特性清单的四种状态:

状态含义
discussion方案讨论,需求未接受
developing开发中
Testing测试中
Accepted已验收

该状态机覆盖了特性从"提出"到"验收"的完整生命周期:特性先进入讨论,被接受后进入开发,再到测试,最终验收通过后随版本发布。清单同时包含sig(负责的 SIG 小组)与owner(责任人)字段,用于明确协作归属,这与 README 中"明确协作规则、提升可追溯性"的仓库定位一致。

4.2 GA 计划中的特性清单为空

当前提交的9.1.0/release-plan.md中,Feature list 表格仅有表头(no / feature / status / sig / owner),尚未填写具体行。结合仓库其他 GA 版本(如 8.5.0)的 release-plan 可见,正式版本计划文档通常承载一份特性清单;而 9.1.0 的特性明细实际记录在三个 Beta 计划的 Feature list 中,GA 计划文档在写作本文章时仍处于待补全状态,这正是计划文档"随研发进度滚动更新"的体现。

4.3 Beta 计划中的已验收特性实例

9.1.0-beta.1(计划文档)记录了两项 Accepted 特性:

nofeaturestatussigowner
1npugraph_ex新增支持SuperKernel融合Acceptedsig-ops-transformercc-z
2aclgraph支持非连续静态算子执行Acceptedsig-ops-transformercc-z

9.1.0-beta.3(计划文档)记录了三项 Accepted 特性:

nofeaturestatussigowner
1卷积算子dX支持stride=kernel和fmap=kernel场景转MatMulAcceptedops-nntangweiwei2
2针对Atlas A2系列产品,AIV模式下搬运类算子支持int64、uint64、float64Acceptedhcclyanyefeng
3针对Atlas A3系列产品,单卡支持创建SIO和HCCS并发channel,通过支持卡内2Die之间多条可用的通信链路,提升通信效率和性能Acceptedhcclyanyefeng

这些条目展示了特性清单的填写范式:每个特性一行,标注验收状态、归属 SIG 与责任人,并以链接形式关联具体 Issue/PR。9.1.0-beta.2 的计划文档则只含时间线、未维护特性清单,说明不同 Beta 计划的内容维护粒度存在差异。

五、从发布计划到发布说明:特性如何落地

发布计划的最终产出体现在同目录的 release-notes.md 中。对照 Beta 计划中的特性条目,可以在版本说明中找到明确对应的交付记录:

  • 计划条目:beta.3 中"卷积算子dX支持stride=kernel和fmap=kernel场景转MatMul"(ops-nn / tangweiwei2)→落地记录:版本说明"ops-nn 库"章节中"卷积算子功能性能优化……dX 支持 stride=kernel 和 fmap=kernel 场景转 MM,优化性能"。
  • 计划条目:beta.1 中"npugraph_ex新增支持SuperKernel融合" → 版本说明"文档变更说明 > 编程指南"中新增"编程指南 > SuperKernel 融合范围标定"章节,二者主题呼应。
  • 部分通信类特性(如 beta.3 中 A3 单卡 SIO/HCCS 并发 channel)未在版本说明中逐条列出,此类特性通常落在对应的 hcomm/hccl 工程内部交付中,体现了"计划文档记录范围与节奏、版本说明记录用户可见变更"的分工。

此外,9.1.0 版本说明 还给出了该版本整体交付的概貌,可视为发布计划"特性收集"阶段所纳入内容的最终形态:

  • 关键特性:新增支持 Ascend 950DT 产品(训练与 Decode 推理场景更高带宽);基于 Atlas A2/A3 与 Ascend 950 系列新增核心算子 SMLA、mHC 等,支持 DeepSeekV4、Qwen3.6、Kimi-K2.6、GLM5.2 等开源模型适配;SHMEM 首发支持 AICore 直驱 MTE/UDMA/RDMA;CATLASS 新增 Tile 组件与 MxFP8/MxFP4 量化模板;算子精度标准开源。
  • 配套关系:CANN 9.1.0 包含 Toolkit、算子包(ops)、加速库(NNAL)三个组合包,与 Ascend HDK 26.0.RC1 配套,并列出与 25.0.X~26.1.0 各驱动版本的兼容矩阵。
  • 工程变更:包含废弃接口迁移(如 aclnnFusedInferAttentionScore → V4 系列)、已修复问题清单与已知问题说明,供升级用户评估风险。

六、如何查阅仓库中的发布计划与历史

仓库采用"版本目录 + 计划/说明双文档"的扁平组织方式,检索发布计划可按以下路径:

  1. 正式版本:查看版本目录下的release-plan.md(如 9.1.0/release-plan.md、9.2.0/release-plan.md),获取该版本的时间线与特性清单。
  2. Beta 里程碑:查看同名版本的-beta.N目录(如 9.1.0-beta.1),了解正式版本研发过程中的阶段性计划。
  3. 补丁版本:补丁版本以独立目录维护(如 9.1.1/release-plan.md),时间线明显短于正式版本;9.1.1/index.md 还提供了"版本说明"索引页,将 GA 版本说明与补丁说明组织在一起,便于追踪同一版本线的演进。
  4. 交付细节:对照同目录release-notes.md(如 9.1.0/release-notes.md),查看特性落地、配套关系、废弃与修复清单。

总结

CANN 9.1.0 的发布计划以"特性收集 → 开发 → 构建 → 三轮测试 → QA 报告 → 发布"的八阶段时间线定义了完整研发节奏,并以"discussion / developing / Testing / Accepted"四种状态对特性清单进行生命周期管理;Beta 计划与 GA 计划分层承载特性明细,最终通过同目录的版本说明完成交付闭环。这套文档体系既是版本研发的作战地图,也是追溯版本内容与协作归属的权威依据,是理解 CANN 版本演进脉络的入口。

  • 文档
  • CANN

【免费下载链接】release-management

CANN版本发布管理仓库

项目地址:https://gitcode.com/cann/release-management
点击查看免费下载

相关推荐

上一篇:如何快速解决RTL8821CE无线网卡问题:Linux用户的完整指南
下一篇:Sphinx C++ 域交叉引用角色误用警告机制详解:以 roles-targets-warn.rst 测试文档为线索

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询