semver规范（语义化版本）
semver 约定一个包的版本号必须包含3个数字，格式必须 为 MAJOR.MINOR.PATCH, 意为 主版本号.小版本号.修订版本号.
版本格式
MAJOR 对应大的版本号迭代，做了不兼容旧版的修改时要更新 MAJOR 版本号
MINOR 对应小版本迭代，发生兼容旧版API的修改或功能更新时，更新MINOR版本号
PATCH 对应修订版本号，一般针对修复 BUG 的版本号
对于包作者（发布者），npm 要求在 publish 之前，必须更新版本号。npm 提供了 npm version 工具，执行 npm version major|minor|patch 可以简单地将版本号中相应的数字加1
常用命令
npm version patch
对于包的引用者来说，我们需要在 dependencies 中使用 semver 约定的 semver range 指定所需依赖包的版本号或版本范围。npm 提供了网站 https://semver.npmjs.com 可方便地计算所输入的表达式的匹配范围。常用的规则示例如下表：
| rang | 含义 | 例子 |
|---|---|---|
| ^2.2.1 | 指定的 MAJOR 版本号下, 所有更新的版本 | 匹配 2.2.3, 2.3.0; 不匹配 1.0.3, 3.0.1 |
| ~2.2.1 | 指定 MAJOR.MINOR 版本号下，所有更新的版本 | 匹配 2.2.3, 2.2.9 ; 不匹配 2.3.0, 2.4.5 |
| >=2.1 | 版本号大于或等于 2.1.0 | 匹配 2.1.2, 3.1 |
| <=2.2 | 版本号小于或等于 2.2 | 匹配 1.0.0, 2.2.1, 2.2.11 |
| 1.0.0 - 2.0.0 | 版本号从 1.0.0 (含) 到 2.0.0 (含) | 匹配 1.0.0, 1.3.4, 2.0.0 |
任意两条规则，用空格连接起来，表示“与”逻辑，即两条规则的交集: 如 >=2.3.1 <=2.8.0 可以解读为: >=2.3.1 且 <=2.8.0
任意两条规则，通过 || 连接起来，表示“或”逻辑，即两条规则的并集: 如 ^2 >=2.3.1 || ^3 >3.2
[注] 除了这几种，还有如下更直观的表示版本号范围的写法:
- * 或 x 匹配所有主版本
- 1 或 1.x 匹配 主版本号为 1 的所有版本
- 1.2 或 1.2.x 匹配 版本号为 1.2 开头的所有版本
[注] 在常规仅包含数字的版本号之外，semver 还允许在 MAJOR.MINOR.PATCH 后追加 - 后跟点号分隔的标签，作为预发布版本标签 - Prerelese Tags，通常被视为不稳定、不建议生产使用的版本。例如：
1.0.0-alpha
1.0.0-beta.1
1.0.0-rc.3
版本格式
当要发布大版本或者核心的Feature时，但是又不能保证这个版本的功能 100% 正常。这个时候就需要通过发布先行版本。比较常见的先行版本包括：内测版、灰度版本了和RC版本。Semver规范中使用alpha、beta、rc(以前叫做gama)来修饰即将要发布的版本。它们的含义是：
- alpha: 内部版本
- beta: 公测版本
- rc: 即Release candiate，正式版本的候选版本
比如：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后需要带上次数信息。
版本发布准则
列举出比较实用的一些规则：
- 标准的版本号必须采用XYZ的格式，并且X、Y 和 Z 为非负的整数，禁止在数字前方补零，版本发布需要严格递增。例如：1.9.1 -> 1.10.0 -> 1.11.0。
- 某个软件版本发行后，任何修改都必须以新版本发行。
- 1.0.0 的版本号用于界定公共 API。当你的软件发布到了正式环境，或者有稳定的API时，就可以发布1.0.0版本了。
- 版本的优先层级指的是不同版本在排序时如何比较。判断优先层级时，必须把版本依序拆分为主版本号、次版本号、修订号及先行版本号后进行比较。