一、实际案例
首先，我们来看看 react 最近 6 个月的版本发布记录，截图来自 npmjs.com：
从上图，我们不难得出几个结论：
- 软件的版本通常由三位组成，形如：X.Y.Z
- 版本是严格递增的，此处是：15.6.1 -> 15.6.2 -> 16.0.0
- 在发布重要版本时，可以发布 alpha、beta、rc 等先行版本
- beta 和 rc 等修饰版本的关键字后面可以带上次数和 meta 信息
二、Semver 简介
在早期，开发者安装某个软件包时，发现这个软件包里又依赖不同特定版本的其它软件包。随着系统功能越来越复杂，依赖的软件包越来越多，依赖关系也越来越深，这个时候可能面临版本控制被锁死的风险。这就是「依赖地狱」的问题。
因此，Github 起草了一个具有指导意义的，统一的版本号表示规则，称为 Semantic Versioning（语义化版本），即 Semver。目前它是由 npm 的团队维护。
Semver 的出现，规定了版本号如何表示，如何增加，如何进行比较，不同的版本号意味着什么。遵从了 Semver 规范的包依赖会非常清晰，不会出现循环依赖、依赖冲突等常见问题。
关于 Semver 的完整规则可以查阅 Semver官网。
下面提炼几个比较关键的要点。
三、版本格式
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
- 主版本号（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.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 的依赖的规则中，还有 ~、>、<、=、>=、<=、-、||、x、X、* 等符号。
当执行 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`
-
x、X、*：表示通配符
`*` 对应所有版本号
`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 文件中对应的版本号。
