3. 版本管理核心概念：语义化版本控制、版本号组成与依赖锁定

聊到版本管理，我猜你第一个想到的就是版本号。但版本号怎么定？什么时候该升主版本？什么时候该升次版本？这些问题，我在团队里见过太多次争论了。今天咱们就把这事彻底聊透。

3.1 语义化版本控制（SemVer）—— 版本号的“交通规则”

语义化版本控制，英文叫 SemVer（Semantic Versioning）。说白了，就是给版本号定一套大家都认的规矩。没有这套规矩，你想想看：A 项目说“我升级了”，B 项目说“我也升级了”，结果一集成，崩了。谁的问题？说不清楚。

SemVer 的核心思想很简单：通过版本号的变化，告诉使用者这次升级的影响范围。我个人习惯，在项目一开始就引入 SemVer，哪怕只是内部库。为什么？因为后期再改，成本太高了。

举个例子：2.5.1，主版本是 2，次版本是 5，修订号是 1。每个数字都有明确的含义。

3.2 版本号组成：主版本、次版本、修订号

咱们一个一个拆开看。

主版本号（MAJOR）

什么时候升主版本？做了不兼容的 API 修改。我在项目中遇到过最典型的场景：重构了一个核心模块，把某个函数的参数顺序改了。结果下游十几个服务全部报错。嗯，那次之后，我定了个规矩——任何破坏性变更，必须升主版本，并且要在 changelog 里写清楚迁移步骤。

• 从 1.x.x 升到 2.0.0：API 不兼容
• 从 2.x.x 升到 3.0.0：同样，不兼容

次版本号（MINOR）

次版本升级，代表向下兼容的功能性新增。说白了，就是加了新功能，但旧代码不用改。比如你给一个库加了个新接口，旧接口照常工作，那就升次版本。

举个例子：1.2.0 → 1.3.0。用户升级后，原有代码不需要任何改动，就能用上新功能。

修订号（PATCH）

修订号，就是向下兼容的问题修正。修 bug、优化性能、改文档，这些都算。我建议：只要改了代码，哪怕只是改了个注释里的拼写错误，也升一下修订号。为什么？因为你要让使用者知道“这个版本和上一个版本有区别”。

比如 1.2.1 → 1.2.2，只是修了个小 bug，不影响任何功能。

版本号部分	变更条件	示例
主版本（MAJOR）	不兼容的 API 修改	1.x.x → 2.0.0
次版本（MINOR）	向下兼容的功能新增	1.0.x → 1.1.0
修订号（PATCH）	向下兼容的问题修正	1.0.0 → 1.0.1

3.3 版本范围与依赖锁定

版本号定好了，怎么用？这就涉及到版本范围和依赖锁定了。

版本范围（Version Range）

在 package.json 或 requirements.txt 里，你经常看到这样的写法："lodash": "^4.17.21"。这个 ^ 就是版本范围的符号。

常见的版本范围符号：

• ~（波浪号）：允许修订号变化。比如 ~1.2.3 匹配 1.2.3 到 1.2.x（不包含 1.3.0）
• ^（脱字符）：允许次版本和修订号变化。比如 ^1.2.3 匹配 1.2.3 到 1.x.x（不包含 2.0.0）
• 精确版本：只匹配指定版本。比如 1.2.3 只匹配 1.2.3

依赖锁定（Lock File）

依赖锁定，就是通过一个锁文件（比如 package-lock.json、yarn.lock、Gemfile.lock），把每个依赖的精确版本固定下来。

我记得有一次，团队里两个人同时开发，一个人装了 lodash@4.17.21，另一个人因为网络问题装了 lodash@4.17.20。结果一个功能在 A 的机器上正常，在 B 的机器上报错。排查了半天，最后发现是 lodash 一个小版本的差异导致的。

从那以后，我强制要求所有项目必须提交锁文件到版本控制。锁文件的作用就是：保证所有人、所有环境安装的依赖版本完全一致。

3.4 实战建议：我常用的版本管理策略

最后，分享几个我个人的实战经验：

1. 主版本号不要轻易升。升主版本意味着要通知所有下游使用者，要写迁移文档，要做兼容测试。我一般只在架构级重构时才升主版本。
2. 次版本号可以频繁升。每加一个功能，就升一次。这样用户能清楚知道每个版本新增了什么。
3. 修订号有 bug 就升。别攒着。我见过有人攒了 10 个 bug 一起发一个修订版本，结果出了问题都不知道是哪个修复引起的。
4. 锁文件一定要提交。这是底线。不提交锁文件的项目，我一般会直接打回。

好了，版本管理的核心概念就这些。下一章咱们聊聊具体的版本控制工具和分支策略。到时候我会分享一些我在 Git 使用上踩过的坑，保证让你少走弯路。