开发规范算是修养，既然是规范了，当然没多大技巧，但是学习后，能让你更快融入团队合作开发和更好管理团队项目，这个是属于内功，因为和语言无关，通用型。

在不同的开发团队，不同的文化，不同的项目背景情况下规范都有可能需要进行适当调整。

无论是API还是软件，都会有一个版本号。那么如何确认一个版本号呢？拍脑袋和盲目累加都不是好的解决方案。好的版本号应该是语义化的，就是别人能从版本知道你更新的程度：大幅度更新、部分功能更新、bug修复等等。 来看看这个：语义化版本号

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

主版本号：当你做了不兼容的 API 修改， 次版本号：当你做了向下兼容的功能性新增， 修订号：当你做了向下兼容的问题修正。

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

  1. 标准的版本号“必须”采用 XYZ 的格式​，其中 X、Y 和 Z 为非负的整数，且“禁止”在数字前方补零。X 是主版本号、Y 是次版本号、而 Z 为修订号。每个元素“必须”以数值来递增。 例如：1.9.1 -> 1.10.0 -> 1.11.0。

这里的递增并没有跨级。我现在用的chrome版本号为：49.0.2623.110，是最典型的例子(注意chrome的主版本号为49.0)。在次版本号(Y)更新加一后有的版本号会这样：1.9.0 -> 2.0.0，这样的变更是不合适的。 简而言之，我们不应该限定XYZ的上限。

  1. 标记版本号的软件发行后，“禁止”改变该版本软件的内容。任何修改都“必须”以新版本发行。

  2. 主版本号为零（0.y.z）的软件处于开发初始阶段，一切都可能随时被改变。这样的公共 API 不应该被视为稳定版。

  3. 1.0.0 的版本号用于界定公共 API 的形成。这一版本之后所有的版本号更新都基于公共 API 及其修改内容。

  4. 修订号(Z)“必须”在只做了向下兼容的修正时才递增。这里的修正指的是针对不正确结果而进行的内部修改。

  5. 此版本号(Y)“必须”在有向下兼容的新功能出现时递增。在任何公共 API 的功能被标记为弃用时也“必须”递增。也“可以”在内部程序有大量新功能或改进被加入时递增，其中“可以”包括修订级别的改变。每当次版本号递增时，修订号“必须”归零。

  6. 主版本号(X)“必须”在有任何不兼容的修改被加入公共 API 时递增。其中“可以”包括次版本号及修订级别的改变。每当主版本号递增时，次版本号和修订号“必须”归零。

  7. 先行版本号“可以”被标注在修订版之后，先加上一个连接号再加上一连串以句点分隔的标识符号来修饰。标识符号“必须”由 ASCII 码的英数字和连接号 [0-9A-Za-z-] 组成，且“禁止”留白。数字型的标识符号“禁止”在前方补零。 先行版的优先级低于相关联的标准版本。被标上先行版本号则表示这个版本并非稳定而且可能无法达到兼容的需求。 范例：1.0​​.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92。

简而言之，现行版本号用连接号连在末尾只能由英文、数字、连接号组成，英文句点分割。

  1. 版本编译信息“可以”被标注在修订版或先行版本号之后，先加上一个加号再加上一连串以句点分隔的标识符号来修饰。标识符号“必须”由 ASCII 的英数字和连接号 [0-9A-Za-z-] 组成，且“禁止”留白。 当判断版本的优先层级时，版本编译信息“可”被忽略。因此当两个版本只有在版本编译信息有差别时，属于相同的优先层级。 范例：1.0.0-alpha+001、1.0.0+20130313144700、1.0.0-beta+exp.sha.5114f85。

命名规则和“现行版本号”一致，但是放在最末尾，用“+”连接。

  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-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0。

Alpha < Beta < RC < Release(正式版)

说了这么大通规则，好处在哪里？ 其实过了一遍规则后，对版本号也有了更深入的了解。我们常见的，比如我的项目中引入了一个第三方的包，现在使用版本为1.2.2。如果版本号使用规范，升级到1.5.0是可以的，甚至在2.0.0以下的版本都是能升级的，因为它们能与原有相依的软件兼容。但是升级到2.0.0就要评估一下，考虑一下做好各项测试。

在我目前接触到的一些开源项目，这样的规范使用的非常广泛。大家可以留心感受一下。

happy hacking~

参考资料： 语义化版本 2.0.0

本作品由 程小白 创作，采用 知识共享署名-相同方式共享 4.0 国际许可协议 进行许可，可自由转载、引用但需署名作者且注明文章出处。
原文地址：https://www.chengxiaobai.cn/skills/the-correct-use-of-the-development-specification-version-number.html