4. 版本命名与版本号治理
在Qualcomm车载FOTA项目中，版本号不是一串随便递增的数字，而是贯穿需求、开发、构建、测试、发布、回滚全链路的“身份标识”。一旦命名规则混乱，轻则导致FOTA包推错车型，重则让T-Box把不兼容的固件刷进错误的硬件SKU，造成变砖。因此，版本治理的核心目标是：让每一个可交付的软件实体，都能被唯一、可解析、可追溯地标识，并且能自动判断“能不能装、该不该升、能不能回滚”。
一、四层标识的分工：语义化版本、构建号、基线号、SKU/变体
Qualcomm车载项目通常同时存在四类标识，它们解决的是不同维度的问题，不能互相替代：
- 语义化版本（SemVer）：面向“功能与兼容性”，格式为
MAJOR.MINOR.PATCH。MAJOR 变更表示不兼容的接口或行为变化；MINOR 表示向后兼容的新功能；PATCH 表示向后兼容的缺陷修复。例如2.4.1表示第2代大版本、第4个功能增量、第1个补丁。 - 构建号（Build Number）：面向“某一次具体编译产物”，通常由CI流水线自动生成，如
B20240612.3或递增整数10457。它保证同一语义化版本下每一次构建都可区分，便于定位测试包与正式包。 - 基线号（Baseline ID）：面向“一组组件的冻结集合”。车载项目常把多个仓库（QNX、Android、MCU、DSP、Modem）在某一时刻的提交锁定为一个基线，如
BL-ADAS-2024Q2-07。基线号是发布与回滚的最小治理单元。 - 硬件SKU与软件变体：面向“同一软件跑在不同硬件配置上”。例如 SA8155P 与 SA8295P 是不同SKU；同一SKU下又可能有“带后排屏/不带后排屏”“国内版/出口版”等软件变体。
这四者组合起来，才构成一个完整的版本身份。推荐的可解析版本串形式为：
SW=2.4.1+B20240612.3
BL=BL-ADAS-2024Q2-07
SKU=SA8295P
VARIANT=CN-PREMIUM
其中 SW 是语义化版本与构建号的组合，BL 是基线号，SKU 与 VARIANT 共同限定目标硬件与配置。FOTA服务器在推送前，必须用这四个字段与车端上报的当前版本做匹配，任何一项不满足兼容矩阵，就应拒绝升级。
二、编码规则：让版本号可被机器解析
版本号治理的第一步是“可解析”。建议在项目内统一约定以下编码规则，并写入构建脚本与FOTA服务端校验逻辑：
- 语义化版本：严格三段式，禁止出现
2.4或2.4.1.3这类非标准写法。预发布版本用-rc.1、-beta.2后缀，且预发布版本不得推送到量产车。 - 构建号：采用
B<yyyyMMdd>.<当日序号>，例如B20240612.3。构建号由CI自动注入，禁止手工修改，保证与代码提交一一对应。 - 基线号：采用
BL-<域>-<年季>-<序号>，例如BL-ADAS-2024Q2-07。域包括 ADAS、IVI、TBOX、MCU 等，便于按域独立冻结与回滚。 - SKU：直接使用Qualcomm芯片型号，如
SA8155P、SA8295P，避免自造缩写。 - 软件变体：采用
<区域>-<配置等级>，如CN-PREMIUM、EU-STD。区域与配置等级必须在项目配置表中预先枚举，不允许自由发挥。
三、冲突消解：当版本号“打架”时怎么办
实际项目中最常见的冲突有四类，处理原则如下：
| 冲突类型 | 典型场景 | 消解策略 |
|---|---|---|
| SKU不匹配 | SA8155P的包被推送到SA8295P车辆 | FOTA服务端在推送前校验SKU字段，不匹配直接拒绝并记录审计日志 |
| 变体越界 | CN-PREMIUM包推送到CN-STD车辆 | 变体白名单机制，只有目标变体在允许列表内才放行 |
| 基线依赖冲突 | 应用要求BL-ADAS-2024Q2-07，车端仍是Q1-05 | 先推送基线升级包，基线就绪后再推送应用包；或打包为组合升级包 |
| 版本回退/降级 | 车端当前2.4.1，目标包2.3.8 | 默认拒绝；仅在回滚窗口内、且由后台显式下发回滚指令时允许 |
四、一个可落地的版本清单示例
下面给出一份可直接用于项目配置的版本清单模板，字段与Qualcomm车载项目实际治理需求对齐：
{
"sw_version": "2.4.1",
"build_number": "B20240612.3",
"baseline_id": "BL-ADAS-2024Q2-07",
"target_sku": "SA8295P",
"variant": "CN-PREMIUM",
"min_baseline": "BL-ADAS-2024Q2-05",
"rollback_window_hours": 72,
"prerelease": false
}
其中 min_baseline 表示允许升级的最低基线，rollback_window_hours 表示回滚窗口时长。FOTA服务端读取该清单后，与车端上报的 current_sw、current_bl、sku、variant 逐项比对，四项全部通过才生成下载任务。这样，版本号就不再是“贴上去的标签”，而是真正参与升级决策的治理数据。
VERSION 文件，并由CI在合并到发布分支时校验其变更是否符合评审记录，防止“悄悄升大版本”导致FOTA兼容矩阵失效。
总结来说，Qualcomm车载FOTA的版本治理，本质上是把“语义化版本、构建号、基线号、SKU与变体”四类标识统一到一套可解析、可校验、可追溯的编码规则中，并用兼容判定矩阵把冲突挡在升级之前。做到这一点，版本号才真正成为质量与安全的守门人，而不是事后扯皮的依据。