1 常见软件的版本命名
常见软件的版本命名举例如下表所示。
| 软件 | 升级过程 | 说明 |
| Linux Kernel | 0.0.1 1.0.0 2.6.32 3.0.18 |
若用X.Y.Z表示，则偶数Y表示稳定版本，奇数Y表示开发版本 |
| Windows | Windows 98 Windows 2000 Windows XP Windows 7 |
最大的特点是杂乱无章，毫无规律 |
| SSH Client | 0.9.8 | |
| OpenStack | 2014.1.3 2015.1.1.dev8 |
可以看到，不同的软件的版本命名风格各异。系统的规模越大，依赖的软件越多，如果这些软件没有遵循一套规范的命名风格，容易造成“Dependency Hell”。所以当我们发布版本时，命名需要遵循某种规则，Semantic Versioning 2.0.0 定义了一套简单的规则及条件来约束版本号的配置和增长。本书根据Semantic Versionning 2.0.0 和 Semantic Versioning 3.0.0选择性地整理出一些版本命名规则。
2 语义化版本命名通行规则
语义化版本命名通行规则对版本的迭代顺序做了很好的规范，其版本号的格式为X.Y.Z（又称Major.Minor.Patch），递增的规则如下表所示。
| 序号 | 升级过程 | 格式要求 |
| X | 非负整数 | 表示主版本号（Major），当API的兼容性发生变化时，X必须递增 |
| Y | 非负整数 | 表示次版本号（Minor），当增加功能时（不影响API的兼容性），Y必须递增 |
| Z | 非负整数 | 表示修订号（Patch），当修复漏洞时（不影响API的兼容性），Z必须递增 |
详细的使用规则如下：
l X、Y、Z必须为非负整数，且不得包含前导零，必须按数值递增，如1.9.0→1.10.0→1.11.0。
l 0.Y.Z表明软件处于初始开发阶段，意味着API可能不稳定；1.0.0表明版本已有稳定的API。
l 当API的兼容性发生变化时，X必须递增，Y和Z同时设置为 0；当新增功能（不影响API的兼容性）或者API被标记为Deprecated时，Y必须递增，同时Z设置为0；当进行漏洞修复时，Z必须递增。
l 先行版本号（Pre-release）意味着该版本不稳定，可能存在兼容性问题，其格式为X.Y.Z.[a-c][正整数]，如1.0.0.a1、1.0.0.b99、1.0.0.c1000。
l 开发版本号常用于CI-CD，格式为X.Y.Z.dev[正整数]，如1.0.1.dev4。
l 版本号的排序规则为依次比较主版本号、次版本号和修订号的数值，如1.0.0<1.0.1<1.1.1< 2.0.0；对于先行版本号和开发版本号，如1.0.0.a100<1.0.0，2.1.0.dev3<2.1.0；当存在字母时，以ASCII的排序来比较，如 1.0.0.a1 < 1.0.0.b1。
注意：版本一经发布，不得修改其内容，有任何修改都必须发布新版本！
3 商业软件中常见的修饰词
商业软件中常见的修饰词如下表所示。
| 描述方式 | 说明 | 含义 |
| Snapshot | 快照版 | 尚不稳定、尚处于开发中的版本 |
| Alpha | 内部版 | 严重缺陷基本完成修正并通过复测，但需要完整的功能测试 |
| Beta | 测试版 | 相对Alpha版有很大的改进，消除了严重的错误，但还存在一些缺陷 |
| RC | 终测版 | Release Candidate（最终测试），即将作为正式版发布 |
| Demo | 演示版 | 只集成了正式版部分功能，无法升级 |
| SP | SP1 | 是Service Pack的意思，表示升级包，相信大家在windows中都见过 |
| Release | 稳定版 | 功能相对稳定，可以对外发行，但有时间限制 |
| Trial | 试用版 | 试用版，仅对部分用户发行 |
| Full Version | 完整版 | 即正式版，已发布 |
| Unregistered | 未注册 | 有功能或时间限制的版本 |
| Standard | 标准版 | 能满足正常使用的功能的版本 |
| Lite | 精简版 | 只含有正式版的核心功能 |
| Enhance | 增强版 | 正式版，功能优化的版本 |
| Ultimate | 旗舰版 | 标配版本的升级，体验更好 |
| Professiona | 专业版 | 针对要求更高、专业性更强的使用群体发行的版本 |
| Free | 自由版 | 自由免费使用的版本 |
| Upgrade | 升级版 | 有功能增强或修复了已知缺陷 |
| Retail | 零售版 | 单独发售 |
| Cardware | 共享版 | 公用许可证（iOS签证） |
| LTS | 维护版 | 该版本需要长期维护 |
4 软件版本号使用限定
为了方便理解，版本限定的语法简述为 [范围描述]<版本号描述>，范围描述可选，必须配和版本描述确定范围，无法独立存在。
l <：小于某一版本号。
l <=：小于或等于某一版本号。
l >：大于某一版本号。
l >=：大于或等于某一版本号。
l =：等于某一版本号，没有意义和直接写该版本号一样。
l ~：基于版本号描述的最新补丁版本。
l ^：基于版本号描述的最新兼容版本。
l -：某个范围，应该出现在两个版本描述中间，实际上语法应为 <版本描述>-<版本描述>,写在此处为了统一。
严格来讲，对~和^的表述需要结合具体的包管理工具和版本号规则来确定，但是一般使用应记住如下原则：
l ^ 是确保版本兼容性时默认对次版本号的限定约束。
l ~ 是确保版本兼容性时默认对补丁号的约束。
5 Spring版本命名规则
Spring版本命名规则如下表所示。
| 描述方式 | 说明 | 含义 |
| Snapshot | 快照版 | 尚不稳定、尚处于开发中的版本 |
| Release | 稳定版 | 功能相对稳定，可以对外发行，但有时间限制 |
| GA | 正式版 | 代表广泛可用的稳定版（General Availability） |
| M | 里程碑版 | 具有一些全新的功能或具有里程碑意义的版本（M是Milestone的意思） |
| RC | 终测版 | Release Candidate（最终测试），即将作为正式版发布 |
本文为“Tom弹架构”原创，转载请注明出处。技术在于分享，我分享我快乐！
如果本文对您有帮助，欢迎关注和点赞；如果您有任何建议也可留言评论或私信，您的支持是我坚持创作的动力。
