Git

1. 主版本号.次版本号.修订号（Semantic Versioning）

这是最常见的版本号命名规则，通常称为语义化版本控制（Semantic Versioning，简称 SemVer）。

规则

  • 主版本号（Major）：当你做了不兼容的 API 修改时，增加主版本号。
  • 次版本号（Minor）：当你做了向下兼容的功能性新增时，增加次版本号。
  • 修订号（Patch）：当你做了向下兼容的问题修正时，增加修订号。

示例

  • 1.0.0：初始版本。
  • 2.0.0：不兼容的 API 修改。
  • 1.1.0：向下兼容的功能性新增。
  • 1.0.1：向下兼容的问题修正。

2. 日期版本号（CalVer）

日期版本号（Calendar Versioning，简称 CalVer）使用日期来命名版本号，通常格式为 YYYY.MM.DD或 YYYY.MM。

规则

  • YYYY：年份。
  • MM：月份。
  • DD：日期（可选）。

示例

  • 2023.10.01：2023年10月1日的版本。
  • 2023.10：2023年10月的版本。

3. 预发布版本号

在正式发布之前，通常会有预发布版本（如 alpha、beta、rc 等）。这些版本号通常在主版本号、次版本号和修订号之后添加后缀。

规则

  • alpha：内部测试版本，通常不稳定。
  • beta：公开测试版本，相对稳定。
  • rc（Release Candidate）：候选发布版本，接近正式发布。

示例

  • 1.0.0-alpha.1：1.0.0 版本的第一个 alpha 版本。
  • 1.0.0-beta.2：1.0.0 版本的第二个 beta 版本。
  • 1.0.0-rc.3：1.0.0 版本的第三个候选发布版本。

4. 构建版本号

构建版本号通常用于标识同一版本的多次构建，特别是在持续集成（CI）环境中。

规则

  • 在版本号后添加构建号或构建标识符。

示例

  • 1.0.0+build.123：1.0.0 版本的第 123 次构建。
  • 1.0.0+20231001.123456：1.0.0 版本，2023年10月1日12:34:56 的构建。

5. 自定义版本号

有些项目可能会使用自定义的版本号命名规则，以适应特定的需求或团队习惯。

示例

  • v1.2.3-feature-x：1.2.3 版本，带有 feature-x 的特性。
  • v2.0.0-hotfix-1：2.0.0 版本，第一个热修复版本。

版本号更新的最佳实践

  1. 明确规则：在项目开始时，明确版本号命名和更新规则，并在文档中记录。
  1. 自动化：使用自动化工具（如 CI/CD 工具）来管理版本号的更新和发布。
  1. 文档化：在每次发布时，更新版本变更日志（Changelog），记录版本的变更内容和影响。
  1. 沟通：在团队内部和用户社区中，及时沟通版本号的变更和发布计划。

总结

版本号的命名和更新规则是软件版本管理中的重要实践。通过遵循明确的规则，你可以清晰地传达版本的变更内容和兼容性，帮助用户和开发者更好地理解和使用你的软件。常见的版本号命名规则包括语义化版本控制（SemVer）、日期版本控制（CalVer）、预发布版本号和构建版本号。
If you have any questions, please contact me.