4. NVIDIA DRIVE平台版本命名与编号规范
在 NVIDIA DRIVE 平台的软件版本治理中，版本号不是一串随手递增的数字，而是一套承载了“功能语义、构建来源、硬件适配范围、车型项目归属”四类信息的结构化标识。如果命名规范缺失，团队很快会陷入“这个包能不能刷到那台车上”“这个版本到底比上一个多了什么”的反复确认中。本节围绕语义化版本、内部构建号、硬件兼容标识、车型项目代号以及它们之间的映射方法展开，目标是让读者能够读懂一个完整的 DRIVE 版本串，并能够按规范自行构造和解析版本标识。
一、四段式版本标识的整体结构
NVIDIA DRIVE 的软件交付通常以“发布版本 + 构建号 + 硬件兼容标识 + 项目代号”组合出现。一个典型的完整标识可以写成如下形式（示例，非真实发布号）：
DRIVE-OS 6.0.8.1-34567890-HW:P3710-PROJ:Orin-X01拆开来看，它由四个语义段构成：语义化版本（6.0.8.1）、内部构建号（34567890）、硬件兼容标识（HW:P3710）、车型项目代号（PROJ:Orin-X01）。四段之间用连字符分隔，段内用冒号区分“类型前缀”和“取值”。这种设计的好处是：任何一段都可以被脚本单独解析，用于筛选、比对和准入判断。
二、语义化版本：对外承诺的兼容性契约
语义化版本采用“主版本.次版本.修订号.补丁号”四段式，与常见的三段式 Semantic Versioning 相比多了一段补丁位，这是为了适配车载软件“小步快跑、频繁热修”的节奏。约定如下：
- 主版本（Major）：出现不兼容的接口变更、驱动 ABI 变化或需要重新刷写引导链时递增。例如从 5.x 升到 6.x，意味着底层 BSP 有破坏性调整。
- 次版本（Minor）：新增向后兼容的功能，如新增一个感知模型、开放一组新的 CAN 信号。
- 修订号（Patch）：向后兼容的问题修复，不改变对外接口。
- 补丁号（Hotfix）：针对已发布版本的紧急修复，通常只改极少量文件，用于产线或召回场景。
需要强调的是，语义化版本描述的是“对外可见的兼容性”，而不是“代码改了多少”。一次内部重构可能改动上万行，但只要接口不变，修订号就可以不动。判断依据应写进发布检查单：接口清单是否变化、ABI 是否变化、配置文件 schema 是否变化。三者皆否，则最多递增修订号。
三、内部构建号：唯一性与可追溯性
构建号由 CI 流水线自动生成，通常是一个单调递增的整数，例如 34567890。它的作用不是表达兼容性，而是保证“任何一个二进制产物都能被唯一定位”。构建号与源码提交号（commit hash）之间应保持一对一映射，建议在构建元数据中同时记录：
build_id: 34567890
commit: a1b2c3d4e5f6
branch: release/drive-6.0
time: 2025-03-11T09:24:17Z
target: p3710-orin当现场反馈某个版本异常时，工程团队应能通过构建号反查到确切的源码状态、编译工具链版本和依赖清单。如果构建号可以重复使用或被手工修改，追溯链就断了。因此规范中应明确：构建号只由流水线写入，任何人工发布包都不得篡改该字段。
四、硬件兼容标识：把版本绑到板子上
DRIVE 平台存在多个芯片与板级形态，例如 Orin、Xavier 以及不同载板设计。硬件兼容标识用于声明“这个软件包是为哪一类硬件编译和验证的”。常见写法是 HW:P3710 这样的平台代号，也可以扩展为带修订的 HW:P3710-B02，其中 B02 表示载板第二版。
硬件兼容标识的判定不能只看芯片型号，还要看：
- 芯片 SKU 与算力档位；
- 载板版本与外围器件（如以太网 PHY、串行器/解串器）差异；
- 引导链与安全启动配置；
- 热设计与功耗档位。
实践中建议维护一张“硬件兼容矩阵”，行是软件版本，列是硬件平台，交叉格填写“已验证 / 未验证 / 不适用”。刷写工具在写入前读取目标板的硬件标识，与包内声明比对，不匹配则直接拒绝，避免把 A 板固件刷进 B 板导致变砖。
五、车型项目代号与版本映射
车型项目代号（如 PROJ:Orin-X01）标识该版本服务于哪个整车项目。同一个软件版本可能同时服务多个项目，也可能因项目定制而分叉。映射方法建议采用“基线 + 项目增量”的方式：
- 确定基线版本，例如
6.0.8.1-34567890-HW:P3710； - 为每个项目维护一份增量清单，记录该项目特有的配置、标定参数和功能开关；
- 发布时生成项目专属标识，如
PROJ:Orin-X01，并在元数据中记录基线构建号； - 若项目增量涉及代码改动，则必须重新走构建流程，生成新的构建号，而不是复用基线构建号。
这样做的价值在于：当某个项目出现问题时，可以快速判断是基线缺陷还是项目增量引入的问题。若多个项目共用同一基线构建号，则基线修复可以一次性惠及所有项目；若某项目私自修改了基线文件，则必须通过新的构建号隔离，防止污染其他项目。
六、版本映射的落地检查
为了让规范真正可执行，发布前应完成以下核对（示例字段，可按项目调整）：
| 检查项 | 示例值 | 判断标准 |
|---|---|---|
| 语义版本递增依据 | 6.0.8.1 → 6.0.8.2 | 仅修复缺陷，接口未变 |
| 构建号唯一性 | 34567890 | 未在历史记录中出现 |
| 硬件兼容标识 | HW:P3710 | 与目标板读取值一致 |
| 项目代号 | PROJ:Orin-X01 | 在项目白名单内 |
| 基线构建号追溯 | 34567890 | 元数据中可查到 commit |
当以上五项全部通过，版本标识才允许进入发布流程。任何一项不满足，都应退回构建或重新映射，而不是靠人工备注“特批”绕过。版本命名规范的本质，是把兼容性判断、硬件准入和项目归属从“人的记忆”转移到“可校验的字段”上，从而让 OTA 分发和产线刷写都能自动化、可审计地运行。