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（最终测试），行将作为正式版公布 |
6 小测一下
本文由“Tom 弹架构”原创，转载请注明出处！技术交换请加微信号 gupaoedu-tom