如何定义软件版本号

一个好的软件产品一定要有个规范的版本号,而在命名版本号时有一些约定俗成的规则。
下面本篇文章就来简单介绍一下 Semver(语义化版本号),希望对大家有所帮助。

一、实际案例

首先,我们来看看目前最流行的前端框架之一的 vue 最近 6 个月的版本发布记录,截图来自npmjs.com

vue最近6个月发布记录

从上图,我们不难得出几个结论:

  • 软件的版本通常由三位组成,形如:X.Y.Z
  • 版本是严格递增的,此处是:2.6.9 -> 2.6.10 -> 2.6.11
  • 在发布重要版本时,可以发布 alpha,rc 等先行版本
  • alpha 和 rc 等修饰版本的关键字后面可以带上次数和 meta 信息
  • 可以说,vue 发布版本时做的相当到位,版本给人的感觉非常清晰,也很严谨。这得益于 Semver(语义化版本) 规范的功劳。

二、Semver 简介

在早期,开发者安装某个软件包时,发现这个软件包里又依赖不同特定版本的其它软件包。随着系统功能越来越复杂,依赖的软件包越来越多,依赖关系也越来越深,这个时候可能面临版本控制被锁死的风险。这就是「依赖地狱」的问题。

因此,Github 起草了一个具有指导意义的,统一的版本号表示规则,称为 Semantic Versioning(语义化版本),即 Semver。目前它是由 npm 的团队维护。

Semver 的出现,规定了版本号如何表示,如何增加,如何进行比较,不同的版本号意味着什么。遵从了 Semver 规范的包依赖会非常清晰,不会出现循环依赖、依赖冲突等常见问题。

关于 Semver 的完整规则可以查阅 Semver官网

下面提炼几个比较关键的要点。

三、版本格式

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

  • 主版本号(major):当你做了不兼容的 API 修改
  • 次版本号(minor):当你做了向下兼容的功能性新增,可以理解为 Feature 版本
  • 修订号(patch):当你做了向下兼容的问题修正,可以理解为 Bug fix 版本

Semver图示

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

四、先行版本

当要发布大版本或者核心的 Feature 时,但是又不能保证这个版本的功能 100% 正常。这个时候就需要通过发布先行版本

比较常见的先行版本包括:内测版、灰度版本和 RC 版本。Semver 规范中使用 alpha、beta、rc(以前叫做 gama)来修饰即将要发布的版本。它们的含义是:

  • alpha: 内部版本。此版本表示该软件在此阶段主要是以实现软件功能为主,通常只在软件开发者内部交流,一般而言,该版本软件的 Bug 较多,需要继续修改。
  • beta: 公测版本。该版本相对于 alpha 版已有了很大的改进,消除了严重的错误,但还是存在着一些缺陷,需要经过多次测试来进一步消除,此版本主要的修改对像是软件的 UI,这个阶段的版本也会一直加入新的功能。
  • rc: 即 Release candiate,正式版本的候选版本。该版本已经相当成熟了,基本上不存在导致错误的 BUG,与即将发行的正式版相差无几,不会再加入新的功能了,主要着重于除错。

比如:1.0.0-alpha.0,1.0.0-alpha.1,1.0.0-beta.0,1.0.0-rc.0,1.0.p-rc.1 等版本。alpha,beta,rc 后需要带上次数信息。

最后,当经过这些先行版本的一系列测试之后,终归会有一个正式版本,是最终交付用户使用的一个版本,也就是 Release 版。

五、版本发布准则

列举出比较实用的一些规则:

  • 标准的版本号必须采用 XYZ 的格式,并且 X、Y 和 Z 为非负的整数,禁止在数字前方补零,版本发布需要严格递增。例如:1.9.1 -> 1.10.0 -> 1.11.0。
  • 某个软件版本发行后,任何修改都必须以新版本发行。
  • 1.0.0 的版本号用于界定公共 API。当你的软件发布到了正式环境,或者有稳定的 API 时,就可以发布 1.0.0 版本了。
  • 版本的优先层级指的是不同版本在排序时如何比较。判断优先层级时,必须把版本依序拆分为主版本号、次版本号、修订号及先行版本号后进行比较。

六、npm 包依赖

npm 的依赖的规则中,还有 ~><=>=<=-||xX* 等符号。

当执行 npm install xxx -S 来安装三方包时,npm 会首先安装包的最新版本,然后将包名及版本号写入到 package.json 文件中。被安装的依赖的版本号前会默认加上 ^ 符号。

比如,通过 npm 安装 vue 时:

{
  "dependencies": {
    "vue": "^2.5.2"
  }
}
  • ^:表示同一主版本号中,不小于指定版本号的版本号
`^2.2.1` 对应主版本号为 2,不小于 `2.2.1` 的版本号,比如 `2.2.1`、`2.2.2`、`2.3.0`,主版本号固定
// 当该依赖有最新版本时(eg:2.3.3),npm install 会安装最新的依赖
  • ~:表示同一主版本号和次版本号中,不小于指定版本号的版本号
`~2.2.1` 对应主版本号为 2,次版本号为 2,不小于 `2.2.1` 的版本号,比如 `2.2.1、2.2.2`,主版本号和次版本号固定
  • ><=>=<=-:用来指定一个版本号范围
 `>2.1`
 `1.0.0 - 1.2.0`
// 注意使用 `-` 的时候,必须两边都有空格。
  • ||:表示或
`^2 <2.2 ||> 2.3`
  • xX*:表示通配符
`*` 对应所有版本号
`3.x` 对应所有主版本号为 3 的版本号

七、npm 包发布

通常我们发布一个包到npm仓库时,我们的做法是先修改 package.json 为某个版本,然后执行 npm publish 命令。手动修改版本号的做法建立在你对 Semver 规范特别熟悉的基础之上,否则可能会造成版本混乱。npm 考虑到了这点,它提供了相关的命令来让我们更好的遵从 Semver 规范:

  • 升级补丁版本号:npm version patch
  • 升级小版本号:npm version minor
  • 升级大版本号:npm version major

当执行 npm publish 时,会首先将当前版本发布到 npm registry,然后更新 dist-tags.latest 的值为新版本。

当执行 npm publish --tag=next 时,会首先将当前版本发布到 npm registry,并且更新 dist-tags.next 的值为新版本。这里的 next 可以是任意有意义的命名(比如:v1.x、v2.x 等等)

OK,接下来用户就可以通过 npm install package@next 来指定安装 next 版本的依赖了。

八、npm 中 package-lock.json 的一些坑

npm install 后,会生成一个 package-lock.json 文件用于保存当前安装依赖的各种来源及版本号。

在 npm 5.4.2 版本后,package-lock.json 的变动规则:

  • 当在 install dependency 的指定版本时,会自动更新 package-lock.json 文件中该 dependency 的 version 到指定的 version
  • 当在 install dependency 的范围版本时,当前的 version 低于 or 等于 package-lock.json 文件中对应的 dependency 的 version 时,会安装 package-lock.json 中的 version
package.json
"antd": "^3.6.1", // eg:最新版本是 3.9.4

package-lock.json
"antd": "3.7.1",

执行npm install 会安装 3.7.1 版本

如果高于 package-lock.json 中对应的 dependency 的 version 时,会安装当前范围版本号中最高的版本,会更新 package-lock.json 文件中对应的版本号。


博文对你有帮助吗?如果有的话,想不想送我一本书呢?
  目录