第2章 版本号命名规范：主版本号、次版本号、修订号规则与预发布版本标记

适用场景

版本号命名规范适用于所有需要进行版本控制的PRD文档。当产品需求文档经历了重大变更、功能迭代、评审修正或处于预发布状态时，必须严格按照本规范更新版本号，以确保版本可追溯、变更可识别、发布状态可区分。本章定义的规范适用于PRD的起草、修订、评审、冻结及新版本发布全生命周期。

前置条件

• PRD文档已创建或已存在基线版本。
• 团队已定义并共识了版本策略（Semantic Versioning 2.0.0 为主流基准规则）。
• 版本管理员或产品经理了解预发布生命周期（如 Alpha、Beta、RC、Release）。

操作步骤

版本号格式严格遵循 MAJOR.MINOR.PATCH（主版本号.次版本号.修订号），可选附加 “预发布版本标记” 和 “构建元数据”。标准操作流程分为4步：

1. 确定主版本号 (MAJOR)：当PRD中发生了不兼容的功能变更或重大方向性调整，包括整体架构重写、核心业务流程重构、对外接口或核心对象模型发生破坏性变更时，主版本号递增1。发生下面任何一条，递增 MAJOR：
   • 整体需求范围发生根本性变化；
   • 原有核心功能被移除或完全替换；
   • 与依赖的外部系统或内部模块的接口协议出现不向下兼容的变动。
2. 确定次版本号 (MINOR)：当PRD中新增了功能、需求模块或优化了现有能力，且这些新增内容与上一个版本保持向后兼容时，次版本号递增1。已发布的 PRD MINOR 版本如果累积了较多小变更，应该进阶到下一 MAJOR。常见情形包括：
   • 新增一个完整的用户故事或功能特性；
   • 插入一个新的需求章节或业务场景；
   • 对现有非破坏性接口进行了拓展。
3. 确定修订号 (PATCH)：当PRD中只进行了修复性、澄清性或微调性修改，且这些修改不新增功能、不改变原有意图时，修订号递增1。包括：
   • 纠正了文字错误、术语不一致或措辞歧义；
   • 更新了引用标准或附录的小版本；
   • 修正了流程图、界面原型中的局部细节。
4. 应用预发布版本标记：当PRD尚处于评审、内部试用或验证阶段，为区分正式发布版本，必须在版本号后附加预发布标记。格式为：MAJOR.MINOR.PATCH-<预发布标识>[.标识序数]。常用标识：alpha（内部开发评审）、beta（外部试点评审）、rc（发布候选评审）。例如：2.1.0-beta.2 表示第2个beta版。预发布版本优先级低于关联的正式版本。

SVG 集成：版本号解析与结构图

输入输出物

责任边界

• 版本管理员：负责执行版本号命名规则，在每次变更生效前对版本号进行合规检查；不得擅自使用非规范的分隔符或自定义数值。
• 产品经理：负责在PRD起草或修订前，根据需求变更范围初步判定应采用的版本号增量级别，并将判定结果写入变更申请单。
• 技术负责人 / 架构师：负责对主版本号变更（MAJOR）进行二次确认，确保架构级破坏性变更已被正确归类。

记录材料

• 版本号声明表：记录版本号全称、递增依据（对应变更ID）、预发布标记生命周期状态（进行中 / 已发布 / 已废弃）。
• 版本号示例与对应变更清单：保存每次版本号变动的详细对照，方便审计回溯。

示例：版本号变更记录片段
PRD版本: 2.0.0 → 3.0.0-alpha.1
变更描述: 重构用户权限模型，移除旧RBAC接口，引入ABAC新框架。
预发布标记: alpha.1 用于内部架构评审。
预期发布为正式版号: 3.0.0（截止RC.0后移除alpha标记）

异常处理

• 版本号冲突：当多人同时修改PRD时，若两方基于同一基线同时生成了相同的新版本号，应以版本管理系统（VCS）时间戳为准，后提交的一方必须递增PATCH并重新评审。
• 遗漏预发布标记：若发现正式版本号被误用于内部预发布文档，立即创建一条 errata 记录，将该版本号标记为“已撤回预发布版”，并重新发布带 -retry.1 标记的新版本。
• 版本号后退：不允许在未进行MAJOR递增的前提下将版本号降级。若必须回退至某历史版本，应使用原本的版本号并附加 -rollback 标记。

验收标准

1. 版本号字符串严格符合 ^\d+\.\d+\.\d+(-[a-zA-Z0-9.]+)?$ 正则约束。
2. 每个版本号与 Git Tag 或 PRD 元数据中的版本号严格一致。
3. 预发布标记在正式发布时必须被完全清除，不允许正式版本号包含连字符或字母。
4. 不同版本号之间不存在增量级别错位（如补丁号未递增时新增了功能却不增加MINOR）。
5. 所有异常处理场景均有对应的版本号操作记录存档。