前言

刚参与CANN开源社区那会，我最懵的就是：版本号咋定的？啥时候发新版本？我提交的PR啥时候能合入？后来把release-management这个仓库读明白，才算搞清楚整个发布流程。

一、仓库定位与核心价值

release-management是昇腾CANN开源社区的发布管理仓库，它不存代码，它存发布流程、版本计划、发版checklist这些东西。

按照仓库的README，它的核心定位是：

• 管理CANN的版本发布流程
• 维护版本计划和发版时间表
• 提供发版checklist和质量控制标准
• 记录历史版本信息和已知问题

这个仓库在CANN五层架构里比较特殊，它不属于任何一层，而是横跨所有层的"发布管理中心"。你可以把它理解为CANN世界的"发布日历"，告诉你啥时候发版本、发版本要做哪些事。

仓库地址：https://atomgit.com/cann/release-management

二、版本管理策略

1. 版本号规则

CANN的版本号规则是主版本.次版本.修订号，比如8.0.1。

规则解读：

• 主版本：大更新，可能有不兼容的API改动。比如从7.x升到8.x，可能有算子接口变了。
• 次版本：功能更新，向后兼容。比如从8.0升到8.1，加了新算子，但老算子还能用。
• 修订号：Bug修复，向后兼容。比如从8.0.0升到8.0.1，修了几个Bug，没加新功能。

示例：

• 7.5.0：主版本7，次版本5，修订号0
• 8.0.0：主版本8，次版本0，修订号0（大版本更新）
• 8.0.1：主版本8，次版本0，修订号1（Bug修复版）

2. 发版节奏

CANN的发版节奏大概是：

• 大版本（主版本更新）：大概1年发1次。比如2024年10月发CANN 8.0，2025年发CANN 8.5。
• 中版本（次版本更新）：大概半年发1次。比如CANN 8.1可能在2025年上半年发。
• 小版本（修订号更新）：按需发布，修Bug就发。比如发现个严重Bug，就发个8.0.1。

为啥这么设计？
大版本要稳，不能老变，不然用户跟不上。中版本可以加新功能，让用户用上新东西。小版本专修Bug，不能引入新功能，保证稳定性。

3. 版本生命周期

每个CANN版本都有生命周期：

• 开发期：大概3-6个月，加新功能、修Bug。
• 候选期：大概1-2个月，发RC（Release Candidate）版本，做最后测试。
• 发布期：正式发版，提供安装包和文档。
• 维护期：发版后至少维护1年，修Bug、 backport补丁。

示例：CANN 8.0的生命周期

• 开发期：2024年1月-7月（7个月）
• 候选期：2024年8月（1个月）
• 发布期：2024年10月（正式发版）
• 维护期：2024年10月-2025年10月（至少1年）

三、发版流程详解

1. 发版checklist

每次发版前，release-management仓库里的checklist会被拿来逐一核对。

checklist包括：

1. 代码冻结：发版前2周，代码冻结，只修Bug，不加新功能。
2. 文档更新：用户手册、API文档、Release Notes都更新到对应版本。
3. 质量控制：跑完所有测试用例，通过率100%才能发版。
4. 兼容性测试：确保新版本和旧版本向后兼容（除非是大版本更新）。
5. 安装包准备：编译好各平台的安装包（Linux x86_64、Linux aarch64、Windows等）。
6. 发布公告：写好Release Announcement，发到社区论坛、邮件列表等渠道。

2. 候选版本（RC）流程

发正式版之前，会先发几个RC版本，让社区测试。

流程：

1. RC1发布：代码冻结后，发第一个候选版本。
2. 社区测试：让社区的用户、开发者都来测，发现问题就提Issue。
3. Bug修复：RC测出来的Bug，修掉，发RC2。
4. 循环迭代：RC2测出来Bug，修掉，发RC3…直到没啥严重Bug了。
5. 正式发版：最后一个RC（比如RC3）没测出严重Bug，就把它打成正式版，发布。

3. 紧急发布流程

如果某个版本有严重Bug（比如安全漏洞、数据丢失风险等），会走紧急发布流程。

流程：

1. Bug确认：确认Bug的严重性，确实需要紧急发版修。
2. 补丁开发：基于出Bug的版本，开发补丁（只修Bug，不加新功能）。
3. 快速测试：跑核心测试用例，确保补丁没引入新问题。
4. 紧急发布：发修订号版本（比如8.0.1），并告知用户尽快升级。

四、适合人群与使用方式

release-management仓库的价值在于，它为不同角色的人提供了不同的使用价值。

1. 普通用户

如果你是用CANN做开发的，这个仓库对你最有用的就是：版本计划和Release Notes。

使用方式：

1. 先看version_plan.md（版本计划），搞清楚下个版本啥时候发、有啥新功能。
2. 再看release_notes/目录，找你要用的版本的Release Notes，搞清楚有啥新功能、修了啥Bug、有啥已知问题。
3. 决定要不要升级（如果新功能你需要，或者修的Bug影响你，就升级；否则可以再等等）。

2. 开发者

如果你是给CANN贡献代码的开发者，这个仓库对你最有用的就是：发版checklist和候选版本时间表。

使用方式：

1. 先看release_checklist.md（发版checklist），搞清楚发版前要做哪些事。
2. 再看rc_schedule.md（候选版本时间表），搞清楚下个RC啥时候发、啥时候截止提交代码。
3. 如果你的PR想合入下个版本，就赶在RC截止前提交，并跟进Review和合入。

3. 维护者

如果你是CANN的维护者（比如Committer、Maintainer），这个仓库就是你发版的"操作手册"。

使用方式：

1. 每次发版前，把release_checklist.md拿出来，逐一核对，确保没漏事。
2. 管理候选版本的发布节奏，确保RC按时发、Bug按时修。
3. 维护版本生命周期，确保老版本在维护期内能拿到Bug修复补丁。

五、与其他仓库的关系

理解release-management的最好方式，是看它和CANN生态中其他仓库的关系。

• 与算子仓库（ops-*）的关系：算子仓库的代码，会通过发版流程，被打进CANN的安装包里。release-management负责协调各个算子仓库的发版节奏，确保它们能赶上大版本发布。

• 与加速库（catlass、ATB）的关系：加速库的代码，也会通过发版流程被打进安装包。release-management会确保加速库和算子仓库的版本兼容性（比如ATB 1.2只能配合CANN 8.0用，不能配合8.1用）。

• 与编译运行时（ge、runtime）的关系：编译运行时的代码，是CANN的核心组件。release-management会确保它们的发版质量（因为一旦出问题，影响所有上层应用）。

一句话总结：各个代码仓库是CANN的"肌肉"，而release-management是CANN的"神经系统"，协调各个部分协同工作，确保每次发版都稳稳当当。

六、总结

release-management这个仓库，对于昇腾CANN社区来说，价值怎么强调都不过分。它定义了版本管理策略、发版流程、质量控制标准，确保CANN能稳定、可预期地演进。

对于普通用户来说，这个仓库帮你搞清楚版本计划、Release Notes，决定要不要升级。

对于开发者来说，这个仓库帮你搞清楚发版节奏、代码截止时间，确保你的PR能合入目标版本。

对于维护者来说，这个仓库是你的"操作手册"，每次发版都照着checklist来，确保不出岔子。

所以，如果你想深入理解CANN的发布机制，或者想让你的代码能合入目标版本，别犹豫，直接去这个仓库看看。别从头到尾读完所有文档，挑和你当前角色相关的部分看。

遇到问题就在Issues里提问，有经验了就帮着完善发版流程文档。大家一起努力，让CANN的发布越来越稳。

仓库地址再发一遍（防止你没记住）：https://atomgit.com/cann/release-management