3. 版本管理基础
在远程OTA升级体系中，版本管理不是简单的“给固件起个名字”，而是贯穿需求、开发、测试、发布、回滚全链路的唯一身份体系。如果版本号混乱、分支随意、标签缺失，OTA平台就无法准确判断“谁该升级、升到哪、能否回退”。本节围绕版本号规范、语义化版本、版本生命周期、分支与标签管理四个核心点展开，建立可落地的版本管理基础。
一、版本号规范：让每个固件都有唯一坐标
版本号是OTA系统识别固件包的第一依据。一个规范的版本号通常由四段构成：主版本号.次版本号.修订号.构建号，例如 2.4.1.20250618。其中主版本号表示不兼容的架构或协议变更；次版本号表示向后兼容的功能新增；修订号表示向后兼容的问题修复；构建号用于区分同一次发布中的多次编译产物，通常与CI流水线编号或日期绑定。
在车规或工业场景中，还常附加硬件型号、区域、渠道等维度，例如 VCU-A-2.4.1-cn-release。这样做的目的是避免“同一版本号对应不同硬件”的致命错误。版本号必须满足三个原则：唯一性（同一版本号不能对应两个不同二进制）、可比较性（能通过规则判断新旧）、可追溯性（能反查代码提交、构建记录和测试报告）。
推荐格式：MAJOR.MINOR.PATCH.BUILD[-硬件型号][-区域][-渠道]
示例：2.4.1.20250618-VCU-A-cn-release
二、语义化版本：用规则表达兼容性承诺
语义化版本（SemVer）的核心是“版本号即契约”。它规定：主版本号递增表示存在不兼容变更；次版本号递增表示新增了向后兼容的功能；修订号递增表示向后兼容的缺陷修复。对于OTA而言，这意味着升级决策可以自动化：如果目标版本与当前版本主版本号一致，通常可执行增量升级；如果主版本号变化，则必须评估硬件资源、配置迁移和回滚策略。
需要特别注意的是，预发布版本和构建元数据在SemVer中有明确优先级。例如 2.4.1-beta.1 低于 2.4.1，而 2.4.1+build.20250618 中的构建元数据不参与优先级比较。OTA平台在筛选“可升级版本”时，必须严格按此规则排序，否则会把测试版误推给正式用户。
# 版本优先级示例（从低到高）
2.4.1-alpha.1
2.4.1-beta.2
2.4.1-rc.1
2.4.1
2.4.2
2.5.0
3.0.0
三、版本生命周期：从草稿到退役的状态流转
版本生命周期描述一个固件版本从创建到停止使用的全过程。典型状态包括：草稿（Draft）→ 构建中（Building）→ 测试中（Testing）→ 候选发布（Release Candidate）→ 正式发布（Released）→ 灰度中（Rolling Out）→ 全量（Full Release）→ 已暂停（Suspended）→ 已退役（Retired）。每个状态对应不同的OTA策略：草稿和构建中不可下发；测试中仅限内部设备；候选发布可进入小范围灰度；正式发布后才允许全量推送；已退役版本不再接受新升级，但需保留回滚包。
生命周期管理的关键是状态机约束：不允许从“草稿”直接跳到“全量”，也不允许“已退役”版本重新激活。OTA平台应记录每次状态变更的操作人、时间、原因和关联工单，形成审计链。
四、版本分支与标签管理：代码与固件的对应关系
分支策略决定“代码怎么并行开发”，标签策略决定“哪个提交对应哪个固件”。常见分支模型包括：主干开发+发布分支、Git Flow、Trunk-Based。对于OTA场景，推荐采用“主干开发+发布分支+标签”的轻量模型：日常功能合入主干；进入测试阶段时从主干切出 release/2.4 分支；每次构建候选版本时在该分支上打标签，如 v2.4.1-rc.1；正式发布后打 v2.4.1 标签，并冻结该分支。
标签必须与固件包、构建流水线、测试报告三者绑定。推荐使用附注标签而非轻量标签，因为附注标签包含打标签人、日期和说明信息，便于审计。同时，标签命名应与版本号严格一致，避免出现 release-2.4.1 与 v2.4.1 混用的情况。
# 创建发布分支与标签示例
git checkout -b release/2.4 main
git tag -a v2.4.1-rc.1 -m "2.4.1 release candidate 1"
git push origin release/2.4 --tags
# 正式发布
git tag -a v2.4.1 -m "2.4.1 official release"
git push origin v2.4.1
五、版本管理检查清单
| 检查项 | 要求 | 常见问题 |
|---|---|---|
| 版本号格式 | 符合 MAJOR.MINOR.PATCH.BUILD 规范 | 日期与构建号混用，无法比较 |
| 语义化兼容性 | 主版本变更必须评估不兼容影响 | 修复缺陷却递增主版本号 |
| 生命周期状态 | 状态流转有审批、有记录 | 草稿版本被误推送到设备 |
| 分支与标签 | 标签与固件包一一对应 | 同一标签对应多个构建产物 |
| 回滚可用性 | 退役版本保留回滚包和元数据 | 回滚时找不到旧版本固件 |
实践建议：将版本号生成、标签创建、固件打包、元数据写入全部纳入CI流水线自动化执行。人工维护版本号是OTA事故的高发源头，自动化校验可以在构建阶段就拦截格式错误、重复版本和非法状态流转。
常见误区：把“版本号”当成“发布次数”，每次发布都简单递增最后一位。这样会导致主版本、次版本的兼容性语义完全丢失，OTA平台无法判断升级风险。另一个误区是只打轻量标签，导致后续无法追溯“这个固件到底由谁、何时、基于哪个提交构建”。
总结来看，版本管理基础可以归纳为四句话：版本号是唯一坐标，语义化版本是兼容性契约，生命周期是状态机，分支与标签是追溯链。只有这四者协同，OTA升级才能做到“可识别、可比较、可控制、可回滚”。