发布版本的建立与变更，核心是把一次交付的范围、质量条件和责任固定下来，并让后续任何调整都有记录可查。本文按版本号规则、建立步骤、变更流程、角色分工、完整示例和验收清单展开，适用于需要管理软件交付版本的研发团队；产品功能版本规划与制品本体的存储分发不在讨论范围内。
要点总览（TL;DR）
- 发布版本建立先用版本号规则固定交付范围：主版本对应不兼容变化，次版本对应向后兼容的功能新增，修订号对应缺陷修复，预发布用后缀标识。
- 建立流程按范围确认、准入条件设定、范围冻结与基线建立、版本记录登记、发布前评审放行五步推进，制品标识是版本记录中不可省略的字段。
- 版本基线后发生范围、时间或内容变化时走变更申请、影响评估、审批和基线更新闭环，变更单需写明回退方案与触发条件。
- 角色分工以版本负责人牵头、审批人保留放行权为原则，研发、测试和发布执行人分别提交技术影响说明、回归结论和发布记录。
- 验收时逐项核对版本号规则、基线可追溯、变更记录完整、发布记录关联制品和回退方案可用，缺项补齐后再关闭版本。
先定版本号规则：让每个发布版本可读、可排序、可追溯
建立发布版本的第一项动作是确定版本号规则。规则要回答三个问题：一个版本号由几段组成、每段在什么条件下递增、版本号如何与需求范围和制品对应。规则确定后应以团队文档形式发布，并在版本评审时作为检查项。
推荐采用“主版本.次版本.修订号”的三段结构，预发布与补丁在此基础上扩展。下表给出可直接套用的规则表：
| 号段 | 含义 | 递增条件 | 示例 |
|---|---|---|---|
| 主版本 | 交付范围或对外契约发生不兼容变化 | 接口、数据结构或使用方式出现不兼容调整 | 2.0.0 → 3.0.0 |
| 次版本 | 向后兼容的功能新增 | 新增需求或功能，旧能力保持可用 | 2.3.0 → 2.4.0 |
| 修订号 | 缺陷修复与补丁 | 仅修复问题，不新增功能、不改变契约 | 2.3.0 → 2.3.1 |
| 预发布后缀 | 未达到正式放行条件的候选版本 | 进入测试或灰度阶段时追加 | 2.3.0-rc.1、2.3.0-beta.2 |
版本号需要与需求范围和制品版本建立对应关系。做法是在版本记录中同时登记版本号、纳入的需求清单编号和制品标识（如构建号或镜像标签），使“这个版本包含哪些需求、对应哪个制品”可以一次查到。版本号规则的评审可以放在版本建立评审中一并完成，规则本身变更时同样要走变更记录，避免规则被个别项目随意改写。
建立发布版本的操作步骤：从范围冻结到版本基线
版本号规则确定后，建立发布版本按以下顺序推进。每一步都有明确输入、动作、输出和完成标志，完成标志未达成不进入下一步。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 确定版本范围 | 需求池、优先级结论 | 挑选纳入本版本的需求，形成需求清单 | 版本需求清单 | 每条需求有负责人和验收口径 |
| 2. 设定准入条件 | 质量要求、历史缺陷数据 | 约定测试通过率、遗留缺陷等级、评审完成情况等门禁 | 准入条件清单 | 条件可量化、可核验 |
| 3. 冻结范围并建立基线 | 需求清单、准入条件 | 停止范围新增，将需求清单与对应文档冻结为版本基线 | 版本基线记录 | 基线有版本号、冻结时间和确认人 |
| 4. 登记版本记录 | 基线、计划安排 | 填写版本号、范围、负责人、计划日期、制品标识 | 版本记录条目 | 字段完整，制品标识可定位 |
| 5. 发布前评审与放行 | 版本记录、测试结论 | 核对准入条件，形成放行结论 | 评审结论与放行记录 | 审批人签字或系统状态为已放行 |
范围冻结是建立阶段的关键节点。冻结之后新增需求不再直接进入本版本，而是转入变更流程处理，这一点需要在团队内明确告知，否则基线会反复失效。版本记录字段中，制品标识尤其容易被省略，缺少它会导致发布后无法确认线上运行的是哪一次构建。
在版本记录与基线管理环节，ONES ALM 研发管理方案围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯；测试用例、缺陷、版本和发布过程也可关联到需求链路中，便于在出现问题时定位影响范围。具体字段配置与操作路径需结合实际部署确认。
发布版本变更怎么走：变更申请、影响评估与审批
版本基线建立后，范围、时间或交付内容发生变化时，应通过版本变更流程处理，而不是在版本记录上直接修改。需要发起变更的典型情况包括：基线后插入或撤出需求、上线窗口调整、制品需要重新构建、已放行版本发现阻断性缺陷。
变更申请单建议包含以下字段，缺项时退回补充：
- 基本信息：变更单编号、关联版本号、申请人、申请日期
- 变更内容：变更类型（范围/时间/内容）、具体调整描述、变更原因
- 影响评估：受影响需求清单、需回归的测试范围、制品是否需重建、上线窗口是否受影响
- 风险与回退：风险等级、回退方案、回退触发条件
- 审批结论：审批人、审批意见、结论（通过/驳回/有条件通过）、生效时间
影响评估要覆盖四个面：需求面确认哪些需求进入或退出，测试面确认回归范围是否扩大，制品面确认是否需要新的构建与标识，上线面确认窗口和依赖系统是否受影响。审批层级按变更风险设定，涉及范围扩大或上线时间调整的变更由版本负责人与审批人共同确认，仅涉及缺陷修复的补丁变更可走简化审批。
变更通过后，版本号与基线同步更新：功能新增进入次版本，纯修复进入修订号，不兼容调整进入主版本；基线重新冻结并保留旧基线记录，形成可对比的两个版本。回退方案要在变更单中写清具体操作和判断条件，不能只写“视情况回退”。ONES 方案以数字线程贯通需求、开发、测试、变更与发布，可支撑影响分析与过程追溯，变更单的具体字段和审批流转需按实际配置落地。
角色与交付物分工：谁提变更、谁评估、谁放行
版本建立与变更涉及五类角色，职责与交付物按下表划分：
| 角色 | 建立阶段职责 | 变更阶段职责 | 主要交付物 |
|---|---|---|---|
| 版本负责人 | 组织范围确认、主持基线冻结、维护版本记录 | 受理变更申请、牵头影响评估、更新版本号与基线 | 版本需求清单、版本记录、变更评估结论 |
| 研发 | 确认需求可实现性、提供制品 | 评估技术影响、执行代码调整并重新提交制品 | 制品标识、技术影响说明 |
| 测试 | 给出测试范围与准入条件建议 | 评估回归范围、出具验证结论 | 测试报告、回归范围清单 |
| 发布执行人 | 确认发布环境与窗口 | 评估上线窗口影响、执行发布或回退 | 发布记录、回退执行记录 |
| 审批人 | 参加发布前评审并放行 | 审批变更申请、确认回退方案 | 放行结论、变更审批意见 |
交接点集中在三处：范围冻结时版本负责人向研发和测试移交需求清单，变更评估时研发与测试向版本负责人提交影响说明，发布放行时版本负责人向审批人提交完整版本记录。职责冲突时，由版本负责人牵头协调范围与排期，审批人保留放行权，技术可行性争议由研发负责人给出结论并记录在变更单中。
一个完整示例：从 2.3.0 建立到 2.3.1 变更
以下为演示情景，用于说明方法如何落地。某团队计划发布 2.3.0，纳入 12 条需求，其中 3 条为新增功能、9 条为体验优化，约定准入条件为严重缺陷清零、测试通过率不低于约定阈值。范围冻结后形成基线，版本记录登记版本号 2.3.0、需求清单编号、版本负责人、计划发布日期和制品标识 build-2301。
测试阶段发现两处缺陷，修复后重新构建，制品标识更新为 build-2305，版本号保持 2.3.0，因为修复发生在放行之前，属于版本内完善。发布前评审通过，2.3.0 放行并生成发布记录。
上线后第三天，业务方提出一条紧急需求，希望在本版本内补充一个报表导出功能。版本负责人发起变更申请，影响评估结论为：新增功能属于向后兼容的功能新增，需追加 2 条测试用例并回归报表模块，制品需重新构建，上线窗口可安排在下个维护窗口。审批通过后，版本号按规则调整为 2.4.0 而非 2.3.1，因为变更内容是功能新增；若该变更仅为修复线上缺陷，则递增为 2.3.1。基线重新冻结，旧基线 2.3.0 保留，发布记录中登记新制品标识与变更单编号，形成从需求到制品的完整追溯链。
完成检查：发布版本建立与变更的验收清单
版本建立或变更完成后，逐项核对以下条目，全部满足才视为闭环：
- 版本号规则唯一且被遵守：本次版本号符合既定递增条件，预发布与补丁标识使用正确
- 范围与基线可追溯：版本记录中的需求清单与基线一致，旧基线在变更后仍可查
- 变更记录完整：每次变更都有申请、影响评估和审批结论，字段无缺项
- 发布记录关联制品：发布记录中的制品标识与实际构建一致，可定位到具体版本
- 回退方案可用：回退步骤具体、触发条件明确，相关角色知晓操作方式
- 角色交付物齐全：测试报告、放行结论、变更审批意见均已归档到对应版本记录
检查中发现缺项时，应回到对应环节补齐后再关闭版本，避免带着不完整的记录进入下一次交付。
常见问题
版本基线冻结后，开发过程中发现必须修复的缺陷，还需要走变更流程吗？
要看修复发生在放行之前还是之后。放行之前修复缺陷并重新构建，版本号保持不变，只需更新制品标识并在版本记录中留下构建变更痕迹；放行之后针对线上缺陷的修复，按修订号递增新版本，并走变更流程登记原因、影响范围和回退方案。判断标准是这次调整是否改变了已放行的交付内容，改变即进入变更流程。
小团队人手有限，变更审批能否简化？
可以按风险分级简化，但简化的是审批人数和层级，申请与评估记录仍需保留。仅涉及缺陷修复、不改变需求范围的补丁变更，可由版本负责人确认、审批人口头或系统内一次性放行；涉及范围扩大、上线窗口调整或不兼容调整的变更，仍应由版本负责人与审批人共同确认。简化规则要事先写进团队流程，避免每次临时决定。
版本号规则由谁维护，规则本身需要变更时怎么处理？
版本号规则通常由版本负责人维护，并在版本建立评审时作为检查项核对。规则本身调整时，同样走变更记录，写明调整原因、受影响的在途版本和迁移方式，避免不同项目各自解释号段含义。规则发布后放在团队文档中，新成员入职和版本启动时对照使用。
发布记录中的制品标识应该记录到什么粒度？
粒度以能唯一定位一次构建为准，常见做法是记录构建号、镜像标签或制品库中的版本标识，并保证该标识在发布后仍可查询。只记录版本号不足以确认线上运行的是哪一次构建，尤其在放行前多次重建的情况下。制品标识与版本号、变更单编号一起登记，出现问题时才能从线上版本反查到需求和代码。
回退方案写到什么程度才算可用？
回退方案要包含具体操作步骤、执行人、触发条件和回退后的验证方式，不能只写“视情况回退”。触发条件应可观察，例如关键接口错误率超过约定阈值或核心流程不可用；回退后要确认数据与配置恢复到预期状态，并记录回退执行结果。发布执行人需在发布前知晓操作方式，必要时提前演练。
