在语义化版本号管理（SemVer）中，主版本号、次版本号和修订号的更新规则有明确的规范。下面我将详细解释每个版本号的定义以及在什么情况下需要增加相应的版本号。
1. 主版本号（Major Version）
- 定义：当你做了不兼容的 API 修改时，需要增加主版本号。
- 何时增加：如果改动破坏了现有用户的使用方式，或者你的代码与之前的版本不兼容，用户在使用新版本时需要做额外的修改或调整才能继续使用，这时就应该增加主版本号。
- 例子：
- 修改了接口或函数的参数类型或返回类型，导致原先使用这些接口的代码无法正常工作。
- 删除或重构了公开 API，导致原本依赖该 API 的用户代码无法运行。
- 大规模的架构变动，如数据库模型更改，数据结构变化，影响了其他系统的集成方式。
- 示例：从
1.0.0升级到2.0.0。
2. 次版本号（Minor Version）
- 定义：当你向下兼容的功能新增或增强时，增加次版本号。
- 何时增加：如果增加了新的功能或改进，且这些变动对现有代码没有破坏性影响，仍然向后兼容，那么就应该增加次版本号。
- 例子：
- 新增了一个功能模块，但现有的功能没有受到影响，依然能够正常工作。
- 添加了向后兼容的新的参数选项或接口，但没有删除或修改现有的接口。
- 在不改变原有行为的前提下优化了某些性能或效率。
- 示例：从
1.1.0升级到1.2.0。
3. 修订号（Patch Version）
- 定义：当你进行向下兼容的 bug 修复时，增加修订号。
- 何时增加：如果做了修复，解决了 bug 或者是提升了现有功能的稳定性，但这些修改并不会改变原有的功能或接口，那么就应该增加修订号。
- 例子：
- 修复了程序中的错误，避免了崩溃或其他异常行为，但没有对功能或 API 做修改。
- 修复了安全漏洞，确保了应用的安全性，但修复过程没有破坏兼容性。
- 提高了系统的稳定性，修复了某些已知问题，但没有引入新的特性或接口变动。
- 示例：从
1.2.3升级到1.2.4。
总结
| 版本号类型 | 什么时候增加 | 示例 |
|---|---|---|
| 主版本号 | 做了不兼容的 API 修改，破坏了现有功能或接口的兼容性 | 删除或修改了 API，导致现有功能不兼容 |
| 次版本号 | 向下兼容的功能新增或增强 | 新增功能、增加新接口或选项 |
| 修订号 | 修复了 bug，提升了稳定性或解决了已知问题，且不影响功能 | 修复问题、提升性能、修复安全漏洞 |
因此，版本号的管理可以帮助用户了解每次发布的修改内容，决定是否需要升级代码，并确保更新后不会对现有系统造成不必要的影响。
Comments NOTHING