软件版本管理规范
文档版本 V1.0 · 更新于 2026 年 11 月 6 日
适用于公司内部业务系统、前端应用、后端服务及微信小程序的软件发布。
一 基本约定
本规范采用“主版本号对应需求、次版本号对应优化、修订号对应 Bug”的内部管理规则。
二 版本号格式与升级规则
正式版本格式为 X.Y.Z，各段均为不带前导零的非负整数。首次纳入本规范的项目，沿用已确认的正式版本作为基线；无版本记录的新项目，首次正式发布使用 1.0.0。
| 版本位 | 对应类型 | 升级规则 | 示例 |
|---|---|---|---|
主版本号 X | 需求 | X 加 1，Y 和 Z 归零 | 1.3.2 → 2.0.0 |
次版本号 Y | 优化 | Y 加 1，Z 归零 | 1.3.2 → 1.4.0 |
修订号 Z | Bug | 仅 Z 加 1 | 1.3.2 → 1.3.3 |
三 任务类型判定
| 任务类型 | 判定依据 | 来源及问题类型 |
|---|---|---|
| 需求 | 任务从需求池发起或拆分而来，统一按需求计算。 | 来源为需求池 |
| 优化 | 任务从问题登记发起，且问题类型为“优化”，按优化计算。 | 来源为问题登记，问题类型为“优化” |
| Bug | 任务从问题登记发起，且问题类型为“bug”，按 Bug 计算。 | 来源为问题登记，问题类型为“bug” |
四 发布批次与版本计算
1. 以发布批次为单位升级，同一批次完成多个同类任务时，对应版本位只增加一次。单个任务或日常 Git 提交无需单独升级正式版本。
2. 混合发布按实际交付任务中的最高类型确定级别，优先级为需求 ＞ 优化 ＞ Bug。延期或移出发布范围的任务不参与计算。
4. 仅修改内部说明文档、注释或任务状态，且不改变交付软件行为、配置及产物时，不单独升级软件版本。依赖、配置或构建变更如改变交付产物，应按任务来源及问题登记中的问题类型归入对应任务类型。
| 当前版本 | 本批次发布内容 | 发布版本 |
|---|---|---|
1.3.2 | 3 个 Bug 修复 | 1.3.3 |
1.3.2 | 2 项优化及 3 个 Bug 修复 | 1.4.0 |
1.3.2 | 1 项需求、2 项优化及 3 个 Bug 修复 | 2.0.0 |
1.3.2 | 5 项需求 | 2.0.0 |
五 测试版本与正式版本
测试阶段在目标正式版本后增加后缀，格式为 X.Y.Z-beta.N，N 从 1 递增。例如 2.0.0-beta.1、2.0.0-beta.2，验证通过后发布 2.0.0。测试轮次不直接增加正式版本的三段数字。
同一目标版本在测试阶段修复发现的问题，继续递增测试后缀。若新增或移出任务导致发布级别变化，应重新计算目标正式版本并更新发布记录。测试版、候选产物均须能够关联到具体提交。