项目版本号管理方案实践

8个月前更新

以下内容来自个人项目版本号管理实践，适合自己的才是最好的。
规范化版本号，可以更有效的管理项目，如版本追溯和生产环境版本回滚。常用版本号格式为：主版本号.次版本号.修订号，也可根据版本状态增加后缀，如 1.0.1-SNAPSHOT 表示 1.0.1 内部测试版本。
实际开发中，频繁迭代会导致版本号增长过快；难以判断某次发布，应该增加次版本号还是修订号？

1. 版本号规范

版本号格式

数字版本号-构建标记
如：1.0.1 、1.0.1-SNAPSHOT、1.0.1-BETA

版本号变化规则

主版本号(MAJOR)：有重大不兼容性变更时增加，如核心功能模块或底层逻辑重构。
次版本号(MINOR)：有新模块、新功能、或重大改进，但保持向后兼容时增加。
修订号(PATCH)：有问题修复、小范围代码优化，不影响功能和兼容性时增加。

构建标记变化规则

开发测试版本：临时版本或内部测试版本，添加 SNAPSHOT 构建标记，如 1.0.1-SNAPSHOT。
准生产版本：已通过验收但未正式发布，添加 RELEASE 构建标记，如 1.0.1-RELEASE。
生产版本：最稳定的正式版本，无构建标记，如 1.0.1。

2.版本管理方案

为了适应不同的项目迭代速度和需求，可选用以下几种管理方案。

基于发布次数的版本管理

通过与发布次数关联的版本号增长方式，简化版本管理，发布更加灵活。
规则：

修订号（PATCH）：每次发布都自增 1，与实际发布频率绑定。如 1.0.1，1.0.2 ，1.0.3 …
次版本号（MINOR）：每发布 10 个修订号版本（PATCH）自动进 1。如 1.0.9 后，下一个版本变为 1.1.0。

适用场景：适用快速迭代的项目。
优点：

版本号按规则自增和进位，有序增长。
减少人为判断，避免纠结某次更新应该增加次版本号还是修订号。

基于固定频率的版本管理

通过采用固定的发布频率，如单周或双周迭代。
适用场景：适合稳定迭代的项目。
优点：

降低发布频率，版本迭代更具规律性。
版本号遵循标准的版本号变化规则，更具可追溯性。
配合紧急发布机制应对高优先级任务（如生产 Bug 修复）。

基于日期的版本管理

以日期作为版本标识，添加 REVISION 后缀用于当日的多次发布。
规则：
采用年.月.日.REVISION 格式。例如，2024 年 10 月 1 日的发布版本号为 1.24.10.01.1（第二次发布则为 1.24.10.01.2）。
适用场景： 适合固定日期发布的项目，或以时间驱动的版本发布。
优点：