软件版本号管理规范 (草案)
1. 版本号格式
正式名称：主版本号.次版本号.修订号 (Major.Minor.Patch)
格式： VX.Y.Z
V： 固定前缀，代表“Version”。X： 主版本号 (Major Version)Y： 次版本号 (Minor Version)Z： 修订号 (Patch Version)
可选扩展：
- 预发布版本标识： 可在正式版发布前使用，例如
V1.2.3-alpha,V1.2.3-beta,V1.2.3-rc.1 - 构建元数据： 可附加构建信息，例如
V1.2.3+20240913,V1.2.3+build.789
2. 各版本号段定义与迭代规则
| 版本段 | 名称 | 决策人 | 迭代规则与说明 |
|---|---|---|---|
| X (主版本号) | 大版本 | 老板/高层 | 1. 不兼容的API修改。 2. 架构颠覆性重构。 3. 产品方向重大调整。 4. 里程碑式新功能集合。 迭代规则： 递增时，Y和Z必须归零。例如： V1.9.4 -> V2.0.0 |
| Y (次版本号) | 功能版本 | 产品经理 | 1. 向下兼容的功能性新增。 2. 计划内的迭代需求完成。 3. 显著的性能优化和体验提升。 迭代规则： 递增时，Z必须归零。例如： V1.1.8 -> V1.2.0 |
| Z (修订号) | 修补版本 | 技术人员 | 1. 向下兼容的问题修复。 2. 紧急线上Bug的hotfix。 3. 无关功能的微小优化或调整。 迭代规则： 顺序递增。例如： V1.0.0 -> V1.0.1 -> V1.0.2 |
3. 决策流程与操作规范
- 起始版本： 项目第一个正式版本应为
V1.0.0。之前的开发阶段可使用V0.Y.Z作为初始开发版本。 - 版本变更流程：
- 修订号 (Z) 变更： 由技术人员（如开发组长）在修复Bug后直接变更，并记录在CHANGELOG（更新日志）中。
- 次版本号 (Y) 变更： 由产品经理在一个迭代周期（Sprint）的所有功能开发、测试完毕，准备发布时提出变更。技术团队同步将修订号归零。
- 主版本号 (X) 变更： 由产品经理或技术负责人发起提案，提交给老板/高层审批。批准后，由技术团队执行版本号变更（Y、Z归零）。
- 代码与标签：
- 版本号必须在项目代码中有一个唯一的、明确的定义位置（如
package.json,pom.xml, 或专门的version.py文件）。 - 在Git中，每一次正式版本发布，都必须打上一个标签 (Tag)，标签名与版本号严格一致，例如
v1.2.3。这是版本追溯的黄金标准。
- 版本号必须在项目代码中有一个唯一的、明确的定义位置（如
- 更新日志 (CHANGELOG)：
- 必须维护一个
CHANGELOG.md文件。 - 每次版本发布，都需记录版本号、日期、变更内容（按“新增功能”、“修复问题”、“破坏性变更”等类别分类）。
- 必须维护一个
4. 常见场景与示例
- 场景一：日常迭代
- 当前版本：
V1.4.5 - 产品经理完成了一个迭代周期，新增了3个功能 -> 版本号变为
V1.5.0
- 当前版本：
- 场景二：线上出现紧急Bug
- 当前版本：
V1.5.0 - 技术人员修复了一个登录Bug -> 版本号变为
V1.5.1
- 当前版本：
- 场景三：公司战略调整，产品大改版
- 当前版本：
V1.9.7 - 经过高层决策，产品进行全面重构，部分API不兼容 -> 版本号变为
V2.0.0
- 当前版本：