适合自己的才是最好的。
规范化版本号，可以更有效的管理项目，如版本追溯和生产环境版本回滚。常用版本号格式为：主版本号.次版本号.修订号，也可根据版本状态增加后缀，如 1.0.1-SNAPSHOT 表示 1.0.1 内部测试版本。
实际开发中，频繁迭代会导致版本号增长过快；同时难以判断某次发布，应该增加次版本号还是修订号？
1. 版本号规范
1.1. 版本号格式
数字版本号-构建标记
如：1.0.1 、1.0.1-RELEASE、1.0.1-SNAPSHOT
1.2. 版本号变化规则
- 主版本号(MAJOR)：有重大不兼容性变更时增加，如核心功能模块或底层逻辑重构。
- 次版本号(MINOR)：有新模块、新功能、或重大改进，但保持向后兼容时增加。
- 修订号(PATCH)：有问题修复、小范围代码优化，不改变功能并保持向后兼容时增加。
1.3. 构建标记变化规则
- 开发测试版本：临时版本或内部测试版本，添加 SNAPSHOT 构建标记，如 1.0.1-SNAPSHOT。
- 准生产版本：已通过验收但未正式发布，添加 RELEASE 构建标记，如 1.0.1-RELEASE。
- 生产版本：最稳定的正式版本，无构建标记，如 1.0.1。
2. 版本管理方案
为了适应不同的项目迭代速度和需求，可选用以下几种管理方案。
2.1. 基于发布次数的版本管理
与发布次数直接关联的版本号增长方式，简化版本管理，发布更加灵活。
规则：
- 修订号（PATCH）：每次发布都自增 1，与实际发布频率绑定。 如 1.0.1，1.0.2 ，1.0.3 ...
- 次版本号（MINOR）：每发布 10 个修订号版本自动进 1。如 1.0.9 后，下一个版本变为 1.1.0。
适用场景：适用快速迭代的项目。
优点：
- 版本号按规则自增和进位，有序增长。
- 减少人为判断，避免纠结某次更新应该增加次版本号还是修订号。
2.2. 基于固定频率的版本管理
采用固定的发布频率，如单周或双周迭代。
适用场景：适合稳定迭代的项目。
优点：
- 降低发布频率，版本迭代更具规律性。
- 版本号遵循标准的版本号变化规则，更具可追溯性。
- 需要完善的紧急发布机制应对高优先级任务，如生产 Bug 修复。
2.3. 基于日期的版本管理
以日期作为版本标识，并添加 REVISION 后缀，应对当日的多次发布。
规则：
采用 年.月.日.REVISION 格式。例如，2024 年 10 月 1 日的发布版本号为 1.24.10.01.1，第二次发布则为 1.24.10.01.2。
适用场景：适合固定日期发布的项目，或以时间驱动的版本发布。
优点：
- 清晰的时间轴，便于历史版本管理和追溯。
- 适合按月发布的项目，但版本号较长，需考虑可读性。
3. 建议
初期阶段：采用基于发布次数的版本管理，快速迭代，减少人为判断带来的版本号混乱。
稳定阶段：转为基于固定频率的版本管理，形成规律的发布周期，有助于长期稳定的版本迭代。
紧急发布：无论采用何种方式，都需要完善的紧急发布机制，来应对高优先级任务和突发问题。
