加密SDK版本管理策略：命名、分支与发布周期
版本管理这事儿，看起来就是定个号、拉个分支，但真踩过坑才知道，随便定一套规则后面有多痛苦。我在维护一个金融级加密SDK时，早期版本号就乱——hotfix和feature版分不清，用户一看版本号完全不知道能不能升，每次升级都心惊胆战。嗯，后来我们痛定思痛，搞了一套标准。今天就跟大家聊聊这套体系。
版本命名规则：一看就懂
我个人习惯用语义化版本规范（SemVer）。说白了就是版本号得有意义，不能是拍脑袋的。
格式：MAJOR.MINOR.PATCH，再加一个可选的预发布后缀。
- MAJOR（主版本号）：不兼容的API变更。比如字段加密算法从AES-256-GCM换成了SM4，或者密钥结构大改。升了这个号，用户必须改代码。
- MINOR（次版本号）：向后兼容的新功能。比如新增了一个加密字段类型，或者优化了性能。升这个号，通常不需要改业务代码。
- PATCH（修订号）：向后兼容的问题修复。比如修了一个边界条件下的解密bug。升这个号，用户可以无脑升级。
预发布后缀呢，我用 -alpha、-beta、-rc.1 这种。比如 2.1.0-beta.2，意思就是第二个beta版本。
| 版本示例 | 含义 | 升级风险 |
|---|---|---|
1.0.0 |
第一个稳定版 | 基线 |
1.0.1 |
修复了一个内存泄漏 | 低 |
1.1.0 |
新增PBKDF2密钥派生功能 | 中 |
2.0.0 |
加密算法全面升级为SM系列 | 高（需重构） |
我的小建议：千万别把版本号和发布日期混在一起。我见过有人用 2024.01.15 当版本号，结果同一天发了两个修复版怎么办？根本区分不开。SemVer才是正解。
分支策略：并行开发与隔离
分支搞不好，版本就乱套了。我个人喜欢用 Git Flow 的变体，针对SDK项目做了些简化。
核心分支就这几个：
main：只放发行版。每个提交都对应一个发布版本，打上版本tag。不允许直接提交代码到main。develop：日常开发集成分支。新功能从develop拉分支，合回来也先合到develop。feature/*：新功能分支。比如feature/sm4-support。开发完了合并回develop。release/*：发布分支。从develop拉出来，只做最后的测试和bug修复，不添加新功能。测试通过后，合并到main并打tag，再合并回develop。hotfix/*：紧急修复分支。从main拉出来，修完合并回main和develop。
# 创建发布分支的例子
git checkout develop
git checkout -b release/2.1.0
# 在release分支上修bug
git commit -m "fix: 修复国密证书解析异常"
# 测试通过后
git checkout main
git merge release/2.1.0 --no-ff
git tag -a v2.1.0 -m "Release version 2.1.0"
git checkout develop
git merge release/2.1.0 --no-ff
git branch -d release/2.1.0避坑指南：我曾经见过一个团队，hotfix修完忘了合并回develop。结果下次发版时，那个紧急修复的代码又丢了。用户气得够呛。记住，hotfix是双线合并——main和develop都得合。
发布周期：节奏要稳
发布周期太随意也不行。我的经验是，SDK发布要兼顾稳定性和响应速度。
我一般这样安排：
- PATCH版本：按需发布，随时响应。安全漏洞需要24小时内出修复版。
- MINOR版本：每2~4周一个。攒够新功能就发一个，别拖太久。
- MAJOR版本：每3~6个月一个。需要提前一个月发beta版让用户测试兼容性。
为什么会这样定？你想想看，加密SDK涉及安全，patch太快可能引入新bug，太慢又怕漏洞被利用。minor版本卡在2~4周，既给了测试时间，又不让用户等太久。
关键点：每个release分支的生命周期里，必须跑完整套回归测试，包括单元测试、集成测试和兼容性测试。没跑完测试的版本，不允许打tag发布。
这套策略跑下来，我最大的体会是——用户能看懂你的版本号，知道该不该升、怎么升，这就是成功。版本管理不是给自己看的，是给用你SDK的人看的。