版本管理：语义化版本控制（SemVer）、版本号策略、版本发布流程、版本回滚与热修复

版本管理这件事，说白了就是给SDK的每一次变化贴个标签。我见过太多团队，版本号乱得像天书——今天发个1.0.0，明天改个1.0.1，后天又跳到了2.0.0。用户根本搞不清哪个版本该用，哪个版本有坑。

嗯，咱们今天就把这事彻底理清楚。

语义化版本控制（SemVer）

语义化版本控制，简称SemVer。它的核心思想很简单：用版本号传递意图。

格式是：主版本号.次版本号.修订号，比如 2.3.1。

• 主版本号：做了不兼容的API修改。用户升级必须改代码。
• 次版本号：新增了功能，但向后兼容。用户升级不会出问题。
• 修订号：做了bug修复。用户升级无感知。

我在项目中遇到过最典型的反例：某个SDK从1.9.0升级到1.10.0，结果删了一个公开接口。用户直接编译失败。为什么？因为团队把「次版本号」当成了「小版本号」在用，根本没遵守SemVer规则。

版本号策略

光有SemVer还不够，你得有一套落地的策略。我个人习惯用这套规则：

1. 开发阶段：版本号以 0.x.y 开头。比如 0.3.2。这表示SDK还不稳定，API随时可能变。
2. 正式发布：从 1.0.0 开始。之后严格遵循SemVer。
3. 预发布版本：加后缀，比如 2.0.0-alpha.1、2.0.0-beta.2、2.0.0-rc.3。alpha是内部测试，beta是公开测试，rc是候选发布。
4. 构建元数据：加 + 号，比如 1.2.3+build.20240301。这信息不参与版本比较，只是记录。

你想想看，如果用户看到 1.2.3-beta.1，他立刻就知道：这是个测试版，别用在生产环境。如果看到 1.2.3，他就知道：这是稳定版，放心用。

版本发布流程

流程不规范，团队两行泪。我建议的发布流程是这样的：

阶段	操作	版本号示例
开发	在develop分支上开发，提交代码	1.2.3-dev
测试	合并到release分支，进行集成测试	1.2.3-beta.1
预发布	修复bug，生成候选版本	1.2.3-rc.1
正式发布	合并到main分支，打tag	1.2.3
热修复	从main分支拉hotfix分支，修复后合并回main和develop	1.2.4

这里有个关键点：每次发布都要打tag。tag名就是版本号，比如 v1.2.3。这样出了问题，你能精确回滚到某个版本。

我记得有一次，团队急着发版，跳过了beta和rc阶段，直接从dev合并到main。结果线上出了严重bug，用户数据都丢了。嗯，从那以后，我再也不敢跳过预发布流程。

版本回滚与热修复

版本回滚，说白了就是「后悔药」。但后悔药也有吃法。

回滚场景：

• 线上发现严重bug，需要立即恢复
• 新版本性能下降，用户投诉
• 依赖的底层服务不兼容

回滚策略：

1. 立即切回上一个稳定版本（比如从1.3.0回退到1.2.9）
2. 通知所有用户，建议降级
3. 在文档中标记1.3.0为「不推荐使用」
4. 修复bug后，发布1.3.1

热修复：

热修复是针对线上紧急bug的快速修复。流程如下：

• 从main分支拉一个hotfix分支
• 修复bug，只改最少的代码
• 版本号只增加修订号（比如从1.2.3到1.2.4）
• 测试通过后，合并回main和develop
• 打tag，发布

我曾经遇到一个情况：用户反馈SDK在某个Android版本上崩溃。我们花了2小时定位问题，发现是某个第三方库的兼容性问题。修复后，我们只改了3行代码，版本号从2.5.0升到2.5.1。用户升级后，问题解决。这就是热修复的价值——快、准、稳。

知识体系总览

下面这张图，帮你把整个版本管理的逻辑串起来：

版本管理这事，说难不难，说简单也不简单。核心就一句话：让版本号替你说话，让流程替你兜底。你按这套规则走，用户信任你，团队也省心。