如何定义软件版本号
# 如何定义软件版本号
一个好的软件产品一定要有个规范的版本号,而在命名版本号时有一些约定俗成的规则。
下面本篇文章就来简单介绍一下 Semver(语义化版本号),希望对大家有所帮助。
# 一. 实际案例
首先,我们来看看目前最流行的前端框架质疑的 vue 抽取 6 个月的版本发布记录,截图来自 npmjs.com (opens new window)
从上图,我们不难得出几个结论:
- 软件的版本通常是由三位组成,形如: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 官网 (opens new window)。
下面提炼几个比较关键的点。
# 三. 版本格式
版本格式:主版本号.此版本号.修订号,版本号递增规则如下
- 主版本号(major):当你做了不兼容的 API 修改。
- 此版本号(minor):当你做了向下兼容的功能性新增,可以理解为 Feature 版本。
- 修订号(patch):当你做了向下兼容的问题修正,可以理解为 Bug fix 版本。
先行版本号及版本编译信息可以加到「主版本号.此版本号.修订号」的后面,作为眼神。
# 四. 先行版本
当要发布 大版本 或者 核心的 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.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 (opens new window) 的依赖的规则中,还有 ~
、>
、<
、=
、 >=
、<=
、-
、||
、x
、X
、*
等符号。
当执行 npm install xxx -S
来安装第三方包时,npm 会首先安装 包的最新版本,然后将包名及版本号写入到 package.json
文件中。被安装的依赖的版本号前会默认加上 ^
符号。
比如,通过 npm 安装 vue 时:
{
"dependencies": {
"vue": "^2.5.2"
}
}
2
3
4
5
^
:表示同一主版本号中,不小于指定版本号的版本号。
`^2.2.1` 对应主版本号为 2,不小于 `2.2.1` 的版本号,比如 `2.2.1`、`2.2.2`、`2.3.0`,主版本号固定
// 当该依赖有最新版本时(eg:2.3.3),npm install 会安装最新的依赖
2
3
~
:表示同一主版本号和次版本号中,不小于指定版本号的版本号。
`~2.2.1` 对应主版本号为 2,次版本号为 2,不小于 `2.2.1` 的版本号,比如 `2.2.1`、`2.2.2`,主版本号和次版本号固定
>
、<
、=
、>=
、<=
、-
:用来指定一个版本号范围。
`>2.1`
`1.0.0 - 1.2.0`
// 注意使用 `-` 的时候,必须两边都有空格
2
3
||
:表示或。
`^2 <2.2 ||> 2.3`
x
、X
、*
:表示通配符。
`*` 对应所有版本号
`3.x` 对应所有主版本号为 3 的版本号
2
# 七. 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 版本
2
3
4
5
6
7
如果高于 package-lock.json 中对应的 dependency 的 version 时,会安装当前范围版本中最高的版本,会更新 package-lock.json 文件中对应的版本号。