版本号规范

版本号规范是软件开发中用于标识软件版本迭代的规则，目的是让开发者、用户清晰理解版本间的兼容性、功能变化等信息。常见的规范主要有以下几种：

一、语义化版本控制（Semantic Versioning，SemVer）

最广泛使用的规范，核心是通过版本号的数字含义传递兼容性信息，格式为：
MAJOR.MINOR.PATCH（主版本号.次版本号.修订号），例如 2.3.1。

各部分含义：

1. MAJOR（主版本号）：
   当进行不兼容的 API 变更时递增（如删除旧接口、修改参数格式导致旧代码无法运行）。
   例：1.0.0 → 2.0.0 表示有破坏性更新，旧版本用户需适配。

2. MINOR（次版本号）：
   当新增向后兼容的功能时递增（如新增接口、扩展功能，不影响旧代码使用）。
   例：2.3.0 → 2.4.0 表示新增功能，旧版本可直接升级。

3. PATCH（修订号）：
   当进行向后兼容的问题修复时递增（如修复 bug，不新增功能，不改变 API）。
   例：2.3.1 → 2.3.2 表示修复了某个 bug。

扩展规则：

• 先行版本号：用于发布测试版本，格式为 MAJOR.MINOR.PATCH-<标识符>，标识符由字母、数字和连接符组成（如 alpha、beta、rc）。
  例：3.0.0-alpha.1（alpha 版本，第一个迭代）、3.0.0-rc.2（候选版本，第二个迭代）。
  先行版本号优先级低于正式版本（如 1.0.0-beta < 1.0.0）。

• 版本编译信息：可选，用于标识构建信息（如构建时间、环境），格式为 MAJOR.MINOR.PATCH+<信息>。
  例：2.1.0+20230510（包含构建日期）、2.1.0+linux.x64（包含运行环境）。

核心原则：

• 版本号从 0.1.0 开始（初始开发阶段，0.MINOR.PATCH 中 MINOR 可频繁变更）。
• 公共 API 稳定后，升级到 1.0.0。
• 递增某一级别时，低级别版本号重置为 0（如 1.2.3 → 2.0.0 时，MINOR 和 PATCH 重置为 0）。

二、日历版本控制（Calendar Versioning，CalVer）

基于日期的版本号规范，适合快速迭代、功能频繁更新的项目（如工具、客户端应用），核心是通过版本号体现发布时间。常见格式有：

1. 年份.月份：如 2023.05（2023 年 5 月发布），代表该月的稳定版本（如 Ubuntu 的 LTS 版本 20.04 表示 2020 年 4 月）。
2. 年份.月份.修订号：如 2023.05.2（2023 年 5 月的第 2 个修订版），用于同月内多次更新。
3. 年份.迭代次数：如 2023.12（2023 年的第 12 次发布）。

特点：

• 无需关注兼容性，用户可通过版本号直观判断发布时间，适合“持续交付”模式。
• 灵活性高，可根据项目需求调整日期粒度（年、月、日）。

三、其他常见规范

1. MAJOR.MINOR.PATCH.BUILD：
   在 SemVer 基础上增加“构建号”（BUILD），用于标识同一版本的不同构建（如编译环境、依赖变化），例 1.2.3.456（第 456 次构建）。适合需要严格追踪构建过程的场景（如客户端软件）。

2. 内部版本号：
   企业内部项目常用，格式灵活，例如：

   • 迭代次数：V1、V2（仅主版本，适合早期项目）。
   • 日期+序号：20230510.1（2023 年 5 月 10 日第 1 个版本）。
   • 分支+版本：dev-1.2.0（开发分支的 1.2.0 版本）。

总结

• SemVer：适合需要明确 API 兼容性的库、框架（如 React、Vue），通过版本号传递“是否需要适配”的信息。
• CalVer：适合快速迭代、用户更关注发布时间的项目（如操作系统、工具类软件）。
• 选择规范的核心是：让团队和用户能通过版本号快速理解版本含义，减少沟通成本。