语义化版本管理

2333

为什么要使用语义化的版本控制?

比如如果主版本号升级了,可以知道项目新增了功能或者是重大问题修复,且都是与旧版本不兼容的,好比大家热切推崇的文本编辑器Sublimetext2和3,他的很多插件在这两个版本间无法兼容使用,所以一般要标明插件是使用在Sublimetext2还是3中。

如果次版本更新了,我们可以知道有小部分新功能添加,或者修订号更新,有小部分bug被修复,而在获取这些信息时完全还没有查看change log。这正是语义化的好处,版本号就告诉你大部分信息了,当然更具体的参见change log吧。

另外个好处就是当大家都在遵循一个规范的时候,无疑扫清了一些认知上的障碍,将事情简单化,大家也心照不宣地能看懂每个人代码中的版本号的意思。

基本规则

顾名思义,语义化的版本就是让版本号更具语义化,可以传达出关于软件本身的一些重要信息而不只是简单的一串数字。
版本格式:主版本号.次版本号.修订号,版本号递增规则如下:

  1. 主版本号:当你做了不兼容的API修改
  2. 次版本号:当你做了向下兼容的功能性新增
  3. 修订号:当你做了向下兼容的问题修正

先行版本号及版本编译信息可以加到"主版本.次版本号.修订号"的后面,作为延伸。

具体规范

  1. 主版本号为零(0.y.z)的处于开发初始阶段,一切都可能随时被改变,这样的公共 API 不应该被视为稳定版。
  2. 1.0.0 的版本号用于界定公共 API 的形成。这一版本之后所有的版本号更新都基于公共 API 及其修改内容。
  3. 修订号 Z(x.y.Z | x > 0)在只做了向下兼容的修正时才递增,这里的修正指的是针对不正确结果而进行的内部修改。
  4. 次版本号 Y(x.Y.z | x > 0)在有向下兼容的新功能出现时递增,在任何公共API的功能被标记为弃用时也递增,也可以在内部程序有大量新功能或改进时递增。每当次版本号递增时修订号必须归零。
  5. 主版本号 X(X.y.z | X > 0)必须在有任何不兼容的修改被加入公共 API 时递增。其中可以包括次版本号及修订级别的改变。每当主版本号递增时,次版本号和修订号必须归零。

开发期

  1. Alpha(α):先行版,被标上先行版本号表示非稳定版本而且可能无法达到兼容的需求,范例:1.0.0-alpha、1.0.0-alpha.1,一般不向外部发布,会有很多Bug。
  2. Beta(β):测试版,或者叫公开测试版,这个阶段的版本会一直加入新的功能,在Alpha版之后推出,范例:1.0.0-beta、1.0.0-beta.1。
  3. RC(Release Candidate):最终测试版本,可能成为最终产品的候选版本,如果未出现问题则可发布成为正式版本,范例:1.0.0-rc、1.0.0-rc.1

版本优先级

版本的优先层级指的是不同版本在排序时如何比较。判断优先层级时,必须把版本依序拆分为主版本号、次版本号、修订号及先行版本号后进行比较。由左到右依序比较每个标识符号,第一个差异值用来决定优先层级:主版本号、次版本号及修订号以数值比较,例如:1.0.0 < 2.0.0 < 2.1.0 < 2.1.1。当主版本号、次版本号及修订号都相同时,改以优先层级比较低的先行版本号决定。例如:1.0.0-alpha < 1.0.0。有相同主版本号、次版本号及修订号的两个先行版本号,其优先层级必须透过由左到右的每个被句点分隔的标识符号来比较,直到找到一个差异值后决定:只有数字的标识符号以数值高低比较,有字母或连接号时则逐字以ASCII的排序来比较。数字的标识符号比非数字的标识符号优先层级低。若开头的标识符号都相同时,栏位比较多的先行版本号优先层级比较高。范例:1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0。

参考文章

语义化版本 2.0.0