应用程序版本号变更规则

尝试更新库之前，应考虑以下注意事项：

• 更新类型。 哪种更新类型可用？ 是小型 bug 修复吗？ 是添加了你需要的新功能吗？ 会中断你的代码吗？ 可以使用称为“语义化版本控制”的系统来传达更新类型。 库版本号的表示方法可向开发人员传达其正在处理的更新类型。
• 是否正确配置了项目。 你可以配置 Node.js 项目，以便只获取需要的更新类型。 仅在特定类型的更新可用时，才会执行更新。 建议使用此方法，因为这样可以避免意外的更新。
• 安全问题。 随着时间推移，管理项目依赖项需要注意可能发生的问题。 检测到漏洞时会出现问题。 理想情况下，将发布你可以下载的修补程序。 npm 工具可帮助你在库上运行审核，以找出是否有应更新的包。 它还可帮助你采取适当的措施来解决问题。

使用语义化版本控制

有一种称为“语义化版本控制”的行业标准。 它是许多公司和开发人员采用的系统。 如果你打算发布包并将其推送到 npm 注册表，则应遵循语义化版本控制。 这是大家所期望的。 即使只是从 npm 注册表下载包，也可期望这些包遵循语义化版本控制。

那么为什么如此重要？ 更改包可能会带来风险。 产生 bug 并损害业务等风险。 可能包括需要重写部分代码的风险。 重写代码会花费时间和成本。

语义化版本控制是指如何表达你或其他开发人员向库引入的更改类型。 语义化版本控制的工作原理是确保包具有版本号，并且该版本号划分为以下部分：

• 主版本：最左边的数字。 例如，1.0.0 中的 1。 此数字发生更改意味着代码可能出现中断性变更。 可能需要重写部分代码。
• 次要版本：中间的数字。 例如，1.2.0 中的 2。 此数字发生更改意味着添加了新功能。 你的代码仍可正常工作。 接受更新通常是安全的。
• 修补程序版本：最右边的数字。 例如，1.2.3 中的 3。 此数字发生更改意味着应用了一个更改，修复了代码中应正常工作的内容。 接受更新应是安全的。

下表显示了每个版本类型的版本号如何更改：

类型	发生的更改
主版本	1.0.0 更改为 2.0.0
次要版本	1.2.9 更改为 1.3.0
修补程序版本	1.0.7 更改为 1.0.8

参见：

管理 Node.js 项目中的依赖项更新 - Learn | Microsoft Docs