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

苏南大叔:什么是semver语义化版本号?如何理解软件版本号? - semver
什么是semver语义化版本号?如何理解软件版本号?(图4-1)

事实上,绝大多数情况下,软件的版本号定义遵循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为例,下面的图显示了其版本号变化:

苏南大叔:什么是semver语义化版本号?如何理解软件版本号? - vuejs-version
什么是semver语义化版本号?如何理解软件版本号?(图4-2)

该图谱来自页面:

主版本号x(major)

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

次版本号y(minor)

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

修订版本号z(patch)

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

补充版本号alphabetarc

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

苏南大叔认为:如果补充信息是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变动。比如:下面的截图,是来自electronpackage.json文件:

苏南大叔:什么是semver语义化版本号?如何理解软件版本号? - package
什么是semver语义化版本号?如何理解软件版本号?(图4-3)

存在的问题

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

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

苏南大叔:什么是semver语义化版本号?如何理解软件版本号? - list-order
什么是semver语义化版本号?如何理解软件版本号?(图4-4)

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

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

相关链接

总结

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

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

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