语义化版本控制和分发标签

语义化版本控制和分发标签

语义化版本

npm 包的版本（version）规范遵循语义化的版本控制：semver。其格式为：x.y.z（x,y,z 只能为数值 [0-9] 且不允许前导补零）

• x (major): 主版本号。
• y (minor): 次版本号。
• z (patch): 修订版本号（补丁版本号）。

版本号的变更必须要遵循以下的要求：

软件包的版本通常从 1.0.0 开始，该版本通常也是软件包的第一个“稳定版本”。当然也可以将主版本号从 0 开始，此时的版本格式为： 0.y.z。这通常表明软件包还处于开发的初始阶段，提供的 API 还不稳定，未来随时可能会改变。

对于主版本号为 0 开头的验证版，其版本变更规则遵循 minor 版本号相当于 major 版本号，patch 版本号则相当于 minor 版本号。

除了最常用的 x.y.z 的标准版本号格式外，语义化版本还提供了另一种类型的版本号 —— 预发布版本号(先行版本号)。预发布版本号通常用于表明软件包处于的不同阶段(Stage)，以更好的帮助软件包的拥有者们有效的分发他们的软件包。

“预发布版本号”与 NPM 的分发标签具有紧密的关联关系。

预发布版本号位于标准格式的补丁版本号之后，使用连字符 - 连接，其格式如:x.y.z-[Identifier]，其中标识符 (Identifier) 是由点号 . 分隔的数字或字母([0-9A-Za-z])组成，除此之外不能含有其它的特殊字符。对于数字型的标识符，不能在前导补零：

matlab

代码解读

复制代码

1.0.0-beta.1 1.0.0-rc 1.0.0-0.3.7

预发布版本号的优先级要低于相关联的标准版本号。通常来说一个主版本或次版本的发布，应要事先分别通过其不同阶段的预发布版本，例如：1.0.0-alpha.0 → 1.0.0-beta.1 → 1.0.0-rc → 1.0.0 。

被标上先行版本号则表示这个版本并非稳定版本而且可能无法满足预期的兼容性需求。

下面是语义化版本必须(MUST)满足的的规则：

1. 版本号必须 >=0 ，且不能在前位补零（前导零）。
2. 递增主版本号需要将次版本号、修订号置 0；递增次版本号需要将修订号置 0，递增修订号，主版本号与次版本号保持不变。
3. 补丁版本号的递增，是兼容性的问题更新，它与具体修复的问题数量无关；次版本号的递增，是兼容性的功能更新，它与具体新增的特性数量无关，哪怕是对已有功能标记废弃，也要递增次版本号。
4. 主版本号为零（0.y.z）的软件处于开发初始阶段，一切都可能随时被改变，建议起始版本号为 0.1.0 ，这样的公共 API 不应该被视为稳定版。所以 1.0.0 版本号是用于界定公共 API 的形成。这一版本之后所有的版本号更新都基于公共 API 及其修改内容。
5. 如果误将一个不兼容的更新通过修订版本或次版本进行了发布，即使这种情况也不能去修改已经发行的包，而是将问题记录到文档中，向使用者公布，并立即更正问题，发布一个修复的次版本或修订版本。

版本范围控制

版本范围语法（Version Range Syntax）是 NPM 独有的特性，但也被众多的包管理器所支持。

通过版本范围语法，可以控制只安装或更新满足特定条件范围内最新版本的 npm 包。这有助于在不牺牲稳定性的情况下自动接收包的更新。要注意的是，版本范围语法只是一个匹配模式，实际下载的依然是一个符合条件的具体版本号的包。

下面是版本范围语法的关键符号：

精确版本号 (1.0.4)

锁定包的版本只能被安装 1.0.4 的版本。

波浪号 (~)

只允许补丁版本更新，只允许安装或更新到最新的修订版号。 eg: 1.0.x

脱字符 (^)

只允许“次版本”与“修订版本”更新。只允许安装或更新到最新的次版本和补丁版本号。 eg：1.x.x

星号 (*)

接受任何版本号更新。需要注意出现的位置，例如 * 、 2.x 、 2.1.x 等。

条件 (>、>=、<、<=)

• > 大于。 eg : > 1.0.4 接受任何大于 1.0.4 版本的更新。
• < 小于。 eg : < 1.0.4 接受任何小与 1.0.4 版本更新。
• <= 小与等于。eg：<= 1.0.4 接受任何小于等于 1.0.4 版本更新。
• >= 大于等于。eg：>=1.0.4 接受任何大于等于 1.0.4 版本更新。

组合条件

组合条件运算。 eg： >1.0.0 <=1.1.0 只可以安装或更新 1.0.1 到 1.1.0 范围内的版本。

范围 (-)

范围 -匹配的是一个闭合区间。eg：1.0.0 - 1.1.0 只可以安装或更新 1.0.0 到 1.1.0 范围的版本。（等价条件范围：≥1.0.0 ≤ 1.1.0 ）

逻辑 (||)

接受任意一个版本，但是 npm 默认总是倾向更新最新的版本。 eg ： 1.0.1 || 1.1.0 || 1.2.0 ，如果没有其它以外，npm 会安装或更新 1.2.0 版本。

[!WARNING] 如果包的版本号是以 0 开头的非稳定版本，此时对于版本范围语法而言，其 minor 版本相当于 major 版本，patch 版本则相当于 minor 版本。

• ^0.14.0 → >= 0.14.0 < 0.15.0
• ~0.14.0 → >=0.14.0 < 0.14.x

如何使用版本范围语法？通常建议直接在 package.json 中修改依赖信息版本号前的匹配符号，然后执行 npm i 或 npm up 命令。

安装依赖时，NPM 默认会往 package.json 内的版本号前插入 ^ 符号。

分发标签 (dist-tag)

与版本范围语法相同，“分发标签(dist-tag)” 也是 NPM 独有的特性。“分发标签”与语义化版本的“预发布版”有着紧密的联系，使用分发标签，可以更好的分发不同阶段的软件包。

查看分发标签

如何在 npm 上查看包版本号的分发标签？

在包详情页面，点击 Version 便可以在 Current Tags 下看到包版本号与其对应的分发标签了。

语义化版本号

分发标签（dist-tag）是包版本号的别名，用以增强包版本号的语义性和可读性

例如，当前安装的依赖 [email protected] 但其目前最新版本为 4.0.0 对应的 dist-tag 为 @latest ，此时要重新安装最新的版本，只需要执行以下命令，使用者无需关心当前的最新版本号。

bash

代码解读

复制代码

npm i foor@latest；

软件包的有效分发

分发标签用于管理和标记发布包的不同版本状态，从而让发布者更有效的分发他们的包。

通常一个软件包的发布过程需要在多个开发流程中去验证，使用分发标签就可以为每个流程创建一个对应的标签，然后总是将流程内最新的版本号与标签进行关联，这样，目标用户就可以很容易的通过分发标签来安装所需流程下最新的软件包版本了。

以 vue 的发布流程为例，主版本与次版本的变更都要经过：先行版本（内部测试 - alpha → 公开测试 - beta → 候选版本 -rc ）→ 正式版 等几个阶段。此时为了方便对应的目标用户安装与测试，便可以对应的创建以下几个分发标签，用于关联每个阶段中最新的版本号：

• @alpha : 总是指向 alpha 阶段的最新版本，例如 [email protected]
• @beta ：总是指向 beta 阶段的最新版本，例如 [email protected]
• @rc ：总是指向候选阶段的最新版本，例如 [email protected]
• @latest 总是指向当前最新的正式版，例如目前最新版本为 [email protected] 。

目标用户群在实际使用时，只需要通过执行 npm i foor@dist-tag ，就可以安装对应阶段内的最新版本的软件包了

bash

代码解读

复制代码

npm i foor@alph npm i foor@beta npm i foor@rc npm i foor@latest

修订版本号的递增不会进入以上的流程，而是直接发布。只有主版本、次版本变更才会进入以上的流程，但主要还是主版本号变更的情况下。

自定义分发标签

分发标签是 npm 的独有产物，一个标签同一时刻只能指向一个版本。

npm 默认内置的分发标签就是 @latest 。对于发布者自定义的标签名称，也同样建议全部使用字母命名，且不以字母 v 开头。例如： alpha 、 beta 、 rc 等。

以 react 为例，它的分发标签就有： canary → ( alpha → beta → rc) → next → latest ，在此之外，React 还有一个特别的分发标签，那就是 experimental (主要用于一些包含实验特性的版本)。

创建分发标签的方式有两种，一种是通过 npm dist-tag 手动创建，然后在发布时同步到 npm 上。

bash

代码解读

复制代码

npm dist-tag add [email protected] beta npm publish

或者使用 npm publish 命令结合 --tag 参数在发布时创建

bash

代码解读

复制代码

npm publish --tag beta

原文链接：https://juejin.cn/post/7418085899714199567