简介

不晓得大家都是怎么定义软件的版本号的？是老老实实的从 1.0 版本开始，还是像埃里森那样间接从 2.0 开始，还是从 beta 版本 0.x 开始呢？

尽管一眼看过来，咱们必定会心愿应用版本号最高的那款软件，因为版本号越高，代表着其迭代越多，性能越稳固。

这里不探讨版本高下的好坏，这里要探讨的是如何让版本谈话。

让版本谈话

为什么要让版本谈话？版本会怎么谈话呢？

让版本谈话的意思是，版本自身就代表肯定的含意，通过版本号就能够根本理解这个版本的大抵状况。

为什么须要管控版本

那么为什么要管控版本呢？那是因为在古代的利用中，一个我的项目须要大量依赖第三方我的项目，而第三方我的项目又会依赖其余的我的项目，从而生成一个宏大的依赖汇合。

在这种宏大的版本依赖状况下，咱们须要大抵上晓得现有的我的项目能够依赖第三方我的项目的大抵版本范畴，从而在依赖我的项目版本升级的状况下，不至于导致本我的项目呈现问题。

所以咱们须要一个版本制订规定。

这就是咱们明天要讲的语义化版本.

语义化版本标准

在语义化版本中，版本号是由三局部组成的, 它的格局是：X.Y.Z（主版本号. 次版本号. 订正号）。

如果只是 bug 的修复，而不影响 API 时，递增订正号, 如果 API 放弃向下兼容的新增及批改时，递增次版本号；如果进行不向下兼容的批改时，递增主版本号。

这样要用什么样的版本是不是很清晰了？

具体而言，X、Y 和 Z 为非负的整数，其中 X 是主版本号、Y 是次版本号、而 Z 为订正号。并且须要遵循上面的一些准则，以保障语义化版本标准的正确性。咱们看下有哪些规定：

1. 在一个版本公布后，禁止对改版本再进行批改。如果须要批改，则递增版本号。
2. 主版本号为 0 的版本，如 0.1.3, 示意软件还在初始的开发阶段，软件并不稳固。
3. 1.0.0 之后的版本才被视为稳固的版本。
4. 如果是对 API 进行外部的 bug 修复，则递增 Z 的值。
5. 如果是新增了向下兼容的新性能，则递增 Y 的值。如果有 API 被标记为废除的话，也须要递增 Y 的值。也能够在蕴含大量的新性能的时候递增 Y 值。每当 Y 值递增的时候，Z 值须要归零。
6. Y 会在增加任何不向下兼容的 API 的时候进行递增。每当主版本号递增时，次版本号和订正号必须归零.
7. 除了主版本之外，还能够在主版本前面增加上后行版本号. 后行版本号是由数字和字母组合而成，以一个连接号接在主版本前面。比方 1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92。后行版本号示意这个版本并非稳固而且可能无奈满足预期的兼容性需要。
8. 在后行版本号或者主版本号前面还能够加上编译版本号。编译版本号也是由数字和字母组合而成，以一个加号接在主版本或者后行版本号的前面。如：1.0.0-alpha+001、1.0.0+20130313144700、1.0.0-beta+exp.sha.5114f85。

总结

以上就是语义化版本的根本阐明，如果大家都依照下面提到的语义化标准来进行版本的编写话，那么咱们的软件世界将会变得有限美妙。

本文已收录于 http://www.flydean.com/03-semantic-version/

最艰深的解读，最粗浅的干货，最简洁的教程，泛滥你不晓得的小技巧等你来发现！

欢送关注我的公众号:「程序那些事」, 懂技术，更懂你！