Spring 版本命名规则

1 常见软件的版本命名

常见软件的版本命名举例如下表所示。

可以看到，不同的软件的版本命名风格各异。系统的规模越大，依赖的软件越多，如果这些软件没有遵循一套规范的命名风格，容易造成“Dependency Hell”。所以当我们发布版本时，命名需要遵循某种规则，Semantic Versioning 2.0.0 定义了一套简单的规则及条件来约束版本号的配置和增长。本书根据 Semantic Versionning 2.0.0 和 Semantic Versioning 3.0.0 选择性地整理出一些版本命名规则。

2 语义化版本命名通行规则

语义化版本命名通行规则对版本的迭代顺序做了很好的规范，其版本号的格式为 X.Y.Z（又称 Major.Minor.Patch），递增的规则如下表所示。

详细的使用规则如下：

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 商业软件中常见的修饰词

商业软件中常见的修饰词如下表所示。

4 软件版本号使用限定

为了方便理解，版本限定的语法简述为 [范围描述]<版本号描述>，范围描述可选，必须配和版本描述确定范围，无法独立存在。

l <：小于某一版本号。

l <=：小于或等于某一版本号。

l >：大于某一版本号。

l >=：大于或等于某一版本号。

l =：等于某一版本号，没有意义和直接写该版本号一样。

l ~：基于版本号描述的最新补丁版本。

l ^：基于版本号描述的最新兼容版本。

l -：某个范围，应该出现在两个版本描述中间，实际上语法应为 <版本描述>-<版本描述>,写在此处为了统一。

严格来讲，对~和^的表述需要结合具体的包管理工具和版本号规则来确定，但是一般使用应记住如下原则：

l ^ 是确保版本兼容性时默认对次版本号的限定约束。

l ~ 是确保版本兼容性时默认对补丁号的约束。

**5 Spring 版本命名规则**

Spring 版本命名规则如下表所示。

本文为“Tom 弹架构”原创，转载请注明出处。技术在于分享，我分享我快乐！

如果本文对您有帮助，欢迎关注和点赞；如果您有任何建议也可留言评论或私信，您的支持是我坚持创作的动力。关注微信公众号“Tom 弹架构”可获取更多技术干货！