什么是semver语义化版本号？如何理解软件版本号？

我们相信：世界是美好的，你是我也是。平行空间的世界里面，不同版本的生活也在继续...

苏南大叔在本文中，要说一下软件版本号的事情。几乎在苏南大叔的每一篇文章中，都在说某个软件的版本号是多少多少。但是这个版本号是怎么来的，定义的规则是怎样的？这个问题似乎值得商榷。

事实上，绝大多数情况下，软件的版本号定义遵循semver语义。这个标准是github组织起草的，是个事实上的行业标准。本文中，苏南大叔就结合自己的理解，说说这个软件版本号的事情。

基本组成

• 一般情况下，基本组成是：x.y.z。
• 最小的版本是0.0.1。一般意味着内测版本。
• 1.0.0 的版本号用于界定公共 API。一般意味着第一次公开正式版本。
• 比较常见的版本号还有：x.y.z-alpha,x.y.z-beta,x.y.z-rc,x.y.z-rc.0,x.y.z-rc.ef16def等。

以目前最炙手可热的vue.js为例，下面的图显示了其版本号变化：

该图谱来自页面：

• https://www.npmjs.com/package/vue

主版本号x(major)

主版本号变更，意味着重大变革。比如：使用方式变化，api变动，构建改动等，并不承诺兼容以前的版本使用方式和api等。

次版本号y(minor)

次版本号变更，意味着较小的变动，向下兼容的功能性更新。如果对应到软件开发的时候，就是Feature，会带来一些新的特性。

修订版本号z(patch)

补充版本号z变化，主要是修正了各种bug问题。如果对应到软件开发的时候，就是bug fix。

补充版本号alpha、beta、rc版

在发布重大版本时，可能会先发布alpha、beta、rc等版本。先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为信息的补充。

苏南大叔认为：如果补充信息是meta版本编译的md5或者sha1之类的话，就很难判断其先后顺序了。不是么？

• alpha是内测版本。
• beta是公测版本。
• rc版是正式版放出之前的可选版本，全称是：Release candiate，最接近正式版。

~和^符号

在使用npm安装依赖的时候，在package.json里面，可以经常看到版本号前面的 ~和^字样。

• ~表示：固定主版本号和次版本号，兼容补丁版本号。比如：~1.2.3，那么1.2.3或者1.2.x或者1.2都是符合条件的。
• ^表示：固定主版本号，兼容次版本号和补丁版本号。比如：^1.2.3，那么1.2.3或者1.x或者1都是符合条件的。
• *表示：啥版本号都行，这个就不说了，大家都明白。

最多的时候，是使用^符号的，也就是说：接受feature更新，不接受api变动。比如：下面的截图，是来自electron的package.json文件：

• https://github.com/electron/electron/blob/main/package.json

存在的问题

对于补充版本号部分，就不能比较版本号大小了。对于apaha,beta,rc一般来说，还有先后顺序。但是有解释为字符串而不是数字的情况，是无法比较大小了。

另外，对于主体形式x.y.z，不允许补充数字0。这样的话，在资源管理器里面排序的时候，顺序就会出现混乱。比如下面的截图所示：

如果允许对主版本号补零，那么顺序就会是正确的。（图上的17排序在2之前，实际上应该在2之后。）

• https://npmmirror.com/mirrors/electron/

苏南大叔认为：在管理器里面的排序问题，是semver语义下的版本号的最大弊病，希望在未来予以改善。

相关链接

• https://semver.org/
• https://semver.org/lang/zh-CN/

总结

软件版本号的semver语义化，是个行业标准。大多数情况下，版本号之间可以比较大小先后顺序。但是由于标准定义：版本号不可以补零，所以，在资源管理器里面排序的时候，会发生一定的混乱。希望在以后这种排序混乱的情况会得到改善。

更多苏南大叔的文章，请点击下面的连接：

• https://seosn.com/

如果本文对您有帮助，或者节约了您的时间，欢迎打赏瓶饮料，建立下友谊关系。
本博客不欢迎：各种镜像采集行为。请尊重原创文章内容，转载请保留作者链接。