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 版本，第一个热修复版本。
版本号更新的最佳实践
- 明确规则：在项目开始时，明确版本号命名和更新规则，并在文档中记录。
- 自动化：使用自动化工具（如 CI/CD 工具）来管理版本号的更新和发布。
- 文档化：在每次发布时，更新版本变更日志（Changelog），记录版本的变更内容和影响。
- 沟通：在团队内部和用户社区中，及时沟通版本号的变更和发布计划。
总结
版本号的命名和更新规则是软件版本管理中的重要实践。通过遵循明确的规则，你可以清晰地传达版本的变更内容和兼容性，帮助用户和开发者更好地理解和使用你的软件。常见的版本号命名规则包括语义化版本控制（SemVer）、日期版本控制（CalVer）、预发布版本号和构建版本号。