多版本维护要解决的是同一产品在多个版本同时在线时，如何确定维护范围、隔离改动、控制准入并稳定发布。可执行的做法是：先列出维护版本清单和下线时间，再为每个版本建立分支与修复回合路径，设定变更准入和冻结窗口，用固定节奏发布并记录版本台账，最后通过检查项确认机制持续运行。本文覆盖版本交付与维护阶段，产品功能版本规划与制品本体管理不在讨论范围内。
要点总览（TL;DR）
- 多版本维护从一份可核对的维护版本清单开始：记录版本号、维护类型、责任团队和计划下线时间，并写明分级依据与退出审批人。
- 并行维护的分支按主干、发布分支、维护分支三层组织，修复先在受影响的最低版本分支提交，再按影响范围回合到其他维护分支和主干。
- 维护版本只接受缺陷修复、安全补丁和必要的兼容性适配，并设置代码冻结、只修阻断问题、发布候选三个冻结阶段，例外变更留审批记录。
- 并行发布用定期维护发布加紧急修复发布的节奏推进，版本台账记录修复项、发布范围、验证结论和发布时间，发布说明与升级指引同步交付客户。
- 机制是否有效按季度检查：版本清单定期评审、回合路径被遵循、冻结与例外留痕、台账完整可追溯、下线版本完成通知与归档。
先定维护哪些版本：版本清单与生命周期规则
多版本维护的第一步是把“维护几个版本”从口头共识变成一份可核对的清单。没有清单，团队容易凭印象接需求，结果是旧版本不断被追加修复，新版本又缺少资源。维护版本清单的作用是让每个在维护的版本都有明确的责任人、维护级别和退出时间。
清单建议至少包含以下字段，并由版本负责人定期更新：
| 字段 | 填写内容 | 示例 |
|---|---|---|
| 版本号 | 对外发布的正式版本标识 | V3.2 |
| 维护类型 | 长期支持、常规维护、仅安全修复 | 常规维护 |
| 责任团队 | 负责该版本修复与发布的团队或个人 | 交付一组 |
| 计划下线时间 | 停止接受缺陷修复的日期 | 2025-06-30 |
| 分级依据 | 支撑该维护级别的合同、装机量或兼容要求 | 两家客户合同承诺至年底 |
生命周期分级需要判断依据，常见的有四类：客户合同中的维护承诺、版本的实际装机量、客户升级到新版本的成本、监管或兼容性要求。判断时把这些依据写进清单，后续调整级别时才有据可查。例如某版本装机量很小但合同承诺了三年支持，就应定为长期支持；某版本装机量大但升级路径顺畅，可以定为常规维护并设定较短的下线时间。
版本进入和退出维护都要有触发条件和审批人。进入维护通常在版本正式发布并通过验收后触发，由版本负责人提出、研发负责人审批。退出维护则由版本负责人在计划下线时间前发起评审，确认没有未完成的合同承诺、客户已收到通知、遗留缺陷已归档，再由研发负责人和客户支持负责人共同批准。审批记录保留在版本台账中，避免下线决定无人负责。
为避免版本无限累积，需要设定收敛规则。常见做法包括：同时处于常规维护的版本不超过两个；新版本发布后，最旧的常规维护版本进入仅安全修复状态；长期支持版本数量按合同约束设上限，超出时需走例外审批。收敛规则不必一刀切，但应写清楚触发条件和决策人，让团队在版本数量增长时有明确的处理路径。
分支与代码线怎么划：并行维护的隔离与回合路径
分支组织的目标是让每个维护版本的改动互不污染，同时保证修复能回到主干，避免维护分支长期分叉。基本结构是主干、发布分支和维护分支三层：主干承载新功能开发；发布分支在版本发布时从主干拉出，用于发布候选验证；维护分支从对应发布点拉出，只接受维护类改动。
命名规则要能一眼看出用途和版本，例如 main 表示主干，release/3.2 表示 3.2 发布分支，maint/3.2 表示 3.2 维护分支。命名规则写入分支模型说明，新成员按规则创建分支，减少随意命名带来的混乱。
缺陷修复的提交路径需要固定下来。推荐做法是：修复先在受影响的最低版本维护分支提交，验证通过后按影响范围依次回合到更高的维护分支，最后回合到主干。这样做的原因是低版本分支的代码基线最旧，先在低版本修复可以尽早暴露兼容性问题；如果先在高版本修复再向下回合，容易因代码差异导致回合失败或引入不兼容改动。
公共修复与版本专属改动要分开处理。公共修复指影响多个版本的同一缺陷，应在一个分支完成修复后回合到其他受影响版本，回合记录写入缺陷单；版本专属改动指只对某个版本有效的适配，例如某客户环境的兼容性补丁，这类改动留在对应维护分支，并在缺陷单中注明不适用的版本，避免误回合。
分支长期存活会带来合并成本和遗漏风险。可以为维护分支设定清理条件：版本下线后，维护分支打上最终标签并归档，不再接受提交；发布分支在版本发布稳定后合并回主干或归档。每季度检查一次长期未回合的分支，列出未回合的提交和原因，由版本负责人决定继续保留还是关闭。
每个版本改什么：缺陷准入与变更冻结窗口
维护版本的改动范围需要提前约定，否则维护分支会逐渐变成第二个开发主线。准入标准的核心是：维护版本只接受缺陷修复、安全补丁和必要的兼容性适配，新功能、重构和体验优化进入主干，按正常版本节奏发布。
可接受的变更类型和不予受理的类型可以整理成准入清单：
| 变更类型 | 是否受理 | 说明 |
|---|---|---|
| 缺陷修复 | 受理 | 需关联缺陷单并标注影响版本 |
| 安全补丁 | 受理 | 按安全响应流程处理，可走紧急发布 |
| 兼容性适配 | 受理 | 需说明适配对象和不影响其他版本的理由 |
| 新功能 | 不受理 | 进入主干，按版本规划发布 |
| 代码重构 | 不受理 | 除非是修复缺陷的必要前置 |
| 界面与体验优化 | 不受理 | 进入主干 |
缺陷优先级和影响版本的判定要一起做。收到缺陷后，先确认它在哪些维护版本中复现，再按业务影响定级：导致客户业务中断或数据错误的定为阻断级，影响主要功能但有临时规避方法的定为高优先级，其余按常规处理。影响版本和优先级共同决定修复排期，阻断级缺陷可以进入紧急修复发布，常规缺陷进入下一次定期维护发布。
冻结窗口是控制发布风险的时间安排。一个维护版本从开发到发布通常经历三个阶段：代码冻结，此后只接受已批准的修复；只修阻断问题，高优先级以下缺陷延到下一版；发布候选，只做验证和发布准备，不再合入代码。冻结窗口的时间表按版本发布节奏提前排定，并通知客户支持和测试团队。
例外变更需要申请和审批记录。客户提出的紧急适配、监管要求的临时补丁，都属于例外变更。申请时写明变更内容、影响版本、风险说明和验证计划，由版本负责人审批，阻断级例外由研发负责人审批。审批记录关联到缺陷单或变更单，发布说明中注明例外变更的来源，便于后续追溯。
发布节奏与版本台账：让并行发布可追踪
多版本并行时，发布节奏要固定下来，让客户支持和客户知道什么时候能拿到修复。常见安排是定期维护发布加紧急修复发布：定期维护发布按固定周期进行，例如每月或每季度一次，集中交付已验收的缺陷修复；紧急修复发布针对阻断级缺陷和安全漏洞，按需触发，不受定期节奏限制。
版本台账是并行发布的记录中心。每个版本每次发布都应在台账中登记，建议字段包括：版本号、包含的修复项、发布范围、验证结论、发布时间。修复项关联缺陷单编号，发布范围说明是全量客户还是特定客户，验证结论记录测试通过情况和遗留问题，发布时间精确到日期。台账由发布协调人维护，版本负责人审核。
发布说明和升级指引是交付给客户的配套材料。发布说明写清楚本次修复了哪些问题、影响哪些功能、是否有行为变化；升级指引写清楚升级前置条件、操作步骤、回滚方式和注意事项。涉及数据库变更或配置调整的版本，升级指引要单独说明，避免客户升级后出现环境问题。
多个版本同时发布时，资源和验证排期需要协调。测试环境、验证人员和发布窗口都是有限资源，建议提前一周排出发布顺序，阻断级紧急发布优先，定期维护发布按版本新旧排序。同一周内发布多个版本时，验证结论分别记录，不共用一份测试报告，确保每个版本的交付状态可独立追溯。
在多版本维护中，版本台账、缺陷记录和发布状态需要在一个地方持续更新，避免信息散落在邮件和表格里。ONES 的工作项与版本管理可以承载缺陷、变更和发布任务的关联记录，让每个版本的修复项、验证结论和发布时间保持可查，版本负责人和发布协调人基于同一份记录推进发布。具体字段和流程可按团队现有习惯配置。
角色分工与交付物：谁对哪个版本负责
多版本维护容易出现责任悬空，原因是版本多、人员交叉，出了问题找不到对应负责人。解决办法是为每个维护版本指定版本负责人，并把其他角色的输入、动作和输出写清楚。
| 角色 | 输入 | 主要动作 | 输出交付物 |
|---|---|---|---|
| 版本负责人 | 维护版本清单、缺陷单、变更申请 | 决定版本改什么、审批例外变更、审核发布 | 版本维护计划、审批记录 |
| 维护开发 | 缺陷单、分支模型说明 | 在维护分支修复、回合到其他版本 | 修复提交、回合记录 |
| 测试 | 修复提交、冻结窗口时间表 | 验证修复、回归受影响功能 | 验证结论、遗留问题清单 |
| 发布协调 | 验证结论、发布节奏安排 | 排定发布窗口、维护版本台账 | 版本台账、发布说明 |
| 客户支持 | 发布说明、升级指引 | 通知客户、收集升级反馈 | 客户通知记录、问题反馈 |
跨版本问题的升级路径要提前约定。当同一缺陷影响多个版本且修复方案存在冲突，或客户要求超出准入标准的变更时，由版本负责人升级到研发负责人决策；涉及合同承诺的，由客户支持负责人参与评估。升级路径写进角色说明，避免问题在团队之间反复流转。
交接和代班需要留记录。版本负责人休假或转岗时，交接内容包括当前维护版本的未完成缺陷、待审批的例外变更、下一次发布计划，交接记录写入版本台账。代班人按同样的权限处理审批，避免因人员变动导致发布停滞。
一个并行维护的示例：三个版本同时收到同一缺陷
以下为演示情景，用于说明前述规则如何串联执行。某产品同时维护 V2.8、V3.1 和 V3.4 三个版本，V2.8 为长期支持，V3.1 为常规维护，V3.4 为当前主版本。客户报告导出功能在特定数据量下报错。
缺陷受理后，测试先在三个版本中复现，确认 V2.8 和 V3.1 均复现，V3.4 因导出模块已重构不复现。按业务影响定级为高优先级：客户业务可继续，但导出功能不可用。版本负责人确认修复进入 V2.8 和 V3.1 的下一次定期维护发布，V3.4 不受影响。
维护开发在 V2.8 维护分支提交修复，验证通过后回合到 V3.1 维护分支。由于 V3.4 已重构，回合时检查代码差异，确认无需合入，在缺陷单中注明不适用版本。回合记录关联到同一缺陷单，便于追溯。
冻结窗口按版本分别执行：V2.8 处于代码冻结阶段，修复作为已批准变更合入；V3.1 处于只修阻断问题阶段，高优先级缺陷按例外变更申请，由版本负责人审批后合入。两个版本的发布时间安排在同一周，V2.8 先发布，V3.1 后发布，测试资源错开使用。
发布协调在版本台账中分别登记两个版本的修复项、发布范围、验证结论和发布时间，发布说明写明导出功能的修复内容和升级注意事项。客户支持向受影响客户发送通知，说明修复版本和升级方式，并收集升级后的反馈。整个链路从缺陷受理到客户通知完成，每个环节都有记录可查。
完成检查：多版本维护机制是否跑起来了
机制建立后需要定期检查是否真正运行。以下检查项可按季度逐项核对，每项给出判断依据，避免只凭印象打分。
- 版本清单与生命周期规则有人维护并定期评审：清单中的版本号、维护类型、责任团队和下线时间与实际一致，评审记录可查。
- 分支与回合路径被实际遵循：抽查近期缺陷单，修复提交在正确的维护分支，回合记录完整；没有长期未回合的分支，或未回合分支已有明确处理决定。
- 冻结窗口与例外变更留有记录：每个维护版本的冻结时间表已通知相关团队，例外变更的申请和审批记录可查，发布说明中注明了例外来源。
- 版本台账完整可追溯：每个已发布版本都有台账记录，修复项、发布范围、验证结论和发布时间齐全，能按版本号查到对应的缺陷单。
- 下线版本按规则完成通知与归档：下线前完成评审和客户通知，维护分支已打标签归档，遗留缺陷已转移或关闭。
检查中发现的问题应形成整改项，指定负责人和完成时间，在下一次评审时复核。机制的价值在于持续运行，清单、分支、准入、台账和角色分工形成闭环后，多版本并行维护才能从救火状态转为可预期的交付节奏。
常见问题
维护版本清单多久评审一次，由谁发起？
建议按季度评审一次，由版本负责人发起，研发负责人和客户支持负责人参与。评审时逐项核对清单中的维护类型、责任团队和计划下线时间是否仍与合同承诺、装机量和升级成本一致，需要调整级别的当场形成结论并更新清单。遇到新签合同承诺或重大版本发布时，可临时增加一次评审。
同一缺陷影响多个版本，修复应该先提交到哪个分支？
先在受影响的最低版本维护分支提交修复，验证通过后再按影响范围依次回合到更高的维护分支，最后回合到主干。低版本分支的代码基线最旧，先在这里修复能尽早暴露兼容性问题；如果先在高版本修复再向下回合，容易因代码差异导致回合失败。若某个高版本已重构、不再包含该模块，回合时确认差异后在缺陷单中注明不适用版本即可。
客户要求把新功能加到正在维护的旧版本，怎么处理？
按准入标准，新功能一般不受理，应进入主干按正常版本节奏发布。如果客户需求来自合同承诺或监管要求，可作为例外变更申请：写明变更内容、影响版本、风险说明和验证计划，由版本负责人审批，阻断级例外由研发负责人审批。审批记录关联到变更单，并在发布说明中注明例外来源，便于后续追溯。
多个维护版本在同一周发布，测试资源怎么安排？
提前一周排出发布顺序：阻断级紧急发布优先，定期维护发布按版本新旧排序。测试环境、验证人员和发布窗口分别排期，避免同一套环境同时验证多个版本。每个版本的验证结论单独记录，不共用一份测试报告，确保交付状态可独立追溯。版本较旧的发布排在前面，可以为后续版本留出处理意外问题的时间。
版本下线时，除了通知客户还需要做哪些收尾动作？
下线前由版本负责人发起评审，确认没有未完成的合同承诺、客户已收到通知、遗留缺陷已转移或关闭，再由研发负责人和客户支持负责人共同批准。技术侧把维护分支打上最终标签并归档，不再接受提交；发布分支按分支模型说明合并回主干或归档。评审和通知记录写入版本台账，避免下线决定无人负责。
