4. IGX版本治理框架设计
IGX平台的OTA升级不是“把新包推上去”这么简单。它涉及Orin SoC上的固件、JetPack/L4T BSP、CUDA与TensorRT运行时、Holoscan SDK、容器化应用以及安全启动链等多个层次。如果版本标识混乱、兼容关系不清，一次看似正常的升级就可能让整机无法启动，或者让上层AI应用因运行时版本不匹配而崩溃。因此，版本治理框架的核心目标只有一句话：让每一个软件组件在任何时刻都有唯一、可追溯、可判断兼容性的版本身份，并明确它何时进入、何时退出支持周期。
一、版本命名规范：从“能看懂”到“能机器解析”
IGX生态中的版本来源多样：NVIDIA官方BSP有L4T版本号，JetPack有独立版本号，Holoscan SDK有自己的语义化版本，客户应用又有内部版本。如果各自为政，运维人员面对一堆“v1.2”“2024.03”“r35.4.1”将无法快速判断谁依赖谁。因此，版本命名规范必须同时满足两个条件：人类可读、机器可解析。
建议采用“产品线-组件-主版本.次版本.修订号-构建元数据”的统一格式，例如：
igx-bsp-5.1.2+build.20240612
igx-holoscan-2.3.0-rc.1
igx-app-perception-1.4.7其中，igx-bsp表示IGX板级支持包，5.1.2是语义化版本主体，+build.20240612是构建元数据，不参与优先级比较，只用于追溯具体构建。对于预发布版本，使用-rc.1、-beta.2后缀，明确其非生产就绪状态。命名规范一旦确定，应写入CI流水线的版本生成脚本，禁止人工随意填写。
二、语义化版本：兼容性承诺的编码表达
语义化版本（SemVer）的核心约定是：主版本号变更表示不兼容的API修改，次版本号变更表示向后兼容的功能新增，修订号变更表示向后兼容的问题修复。在IGX场景中，这一约定需要映射到具体组件行为上。
以Holoscan SDK为例，若从2.3.0升级到2.4.0，意味着新增了算子或接口，但原有算子签名、数据流图定义方式不变，现有应用无需修改代码即可重新编译运行。若从2.x升级到3.0.0，则可能删除了旧算子、修改了执行上下文接口，应用必须适配。对于BSP而言，L4T从r35.x到r36.x通常伴随内核版本、设备树和启动链的较大变化，应视为不兼容升级，必须经过完整的回归验证。
三、版本矩阵：把兼容关系变成可查询的表
版本矩阵是治理框架的“事实来源”。它用二维表明确记录：某一IGX BSP版本下，哪些JetPack、CUDA、TensorRT、Holoscan SDK和容器基础镜像版本是经过验证的组合。矩阵中的每一行代表一个受支持的平台基线，每一列代表一个组件维度。
例如，一个简化的IGX版本矩阵可以包含以下字段：
| IGX BSP | L4T | JetPack | CUDA | TensorRT | Holoscan SDK | 状态 |
|---|---|---|---|---|---|---|
| 5.1.2 | r35.4.1 | 5.1.2 | 11.4 | 8.5.2 | 2.3.0 | 生产支持 |
| 5.1.0 | r35.3.1 | 5.1.0 | 11.4 | 8.5.2 | 2.2.0 | 维护支持 |
| 6.0.0-rc.1 | r36.2.0 | 6.0.0 | 12.2 | 8.6.1 | 3.0.0-rc.1 | 预发布验证 |
版本矩阵必须由发布工程团队维护，并随每次BSP或SDK发布更新。OTA升级服务在推送前，应查询矩阵确认目标版本组合是否处于“生产支持”或“维护支持”状态，避免将预发布组合误推到生产设备。
四、兼容性策略：向前、向后与跨代升级的边界
兼容性策略需要回答三个问题：新应用能否跑在旧BSP上？旧应用能否跑在新BSP上？跨大版本升级需要哪些额外步骤？
对于IGX，建议采用“向后兼容优先、向前兼容受限、跨代升级强制验证”的策略。向后兼容指新版本BSP应尽量支持旧版Holoscan应用，至少在次版本升级范围内保证二进制兼容。向前兼容则通常不承诺：为L4T r36编译的应用不应期望在r35上运行。跨代升级（如r35到r36）必须经过启动链验证、内核模块检查、容器运行时兼容性测试和AI推理精度回归。
在OTA包设计上，可以通过依赖声明表达兼容边界。例如，一个应用容器镜像的元数据中声明：
requires:
igx-bsp: ">=5.1.0, <6.0.0"
holoscan-sdk: ">=2.3.0, <3.0.0"
cuda: ">=11.4"升级代理在安装前解析这些约束，若不满足则拒绝升级并上报原因，而不是强行安装后导致运行时故障。
五、生命周期管理原则：每个版本都有明确的“出生”与“退役”
版本治理不能只关注“当前最新”，还要管理“旧版本何时退出”。建议为每个IGX平台基线定义四个生命周期阶段：预发布、生产支持、维护支持、停止支持。预发布阶段仅用于内部验证和早期客户测试；生产支持阶段提供完整修复和新功能；维护支持阶段只修复安全漏洞和严重缺陷；停止支持后不再发布任何补丁，OTA服务也不再向该基线推送更新。
生命周期策略应与NVIDIA官方L4T/JetPack的支持周期对齐，但可以更严格。例如，NVIDIA对某一L4T版本提供18个月支持，企业若因安全合规要求需要24个月，则应在内部延长维护支持阶段，并自行承担补丁回移工作。所有生命周期状态应记录在版本矩阵中，并通过OTA服务暴露给运维看板，使设备当前所处支持阶段一目了然。
六、把治理框架落到OTA流程中
上述四个部分不是孤立文档，而应嵌入OTA升级的实际决策链。当升级代理收到一个目标版本时，它按以下顺序判断：首先解析版本命名，确认组件身份和语义化版本号；然后查询版本矩阵，确认目标组合是否受支持；接着检查兼容性约束，确认当前设备基线是否满足依赖声明；最后查询生命周期状态，若目标版本已进入“停止支持”，则拒绝升级并告警。
这一判断链可以用一个简单的决策表来表达：
| 检查项 | 通过条件 | 不通过动作 |
|---|---|---|
| 版本命名解析 | 符合统一格式，组件与版本号可识别 | 拒绝安装，记录格式错误 |
| 版本矩阵匹配 | 目标组合状态为“生产支持”或“维护支持” | 拒绝安装，提示组合未验证 |
| 兼容性约束 | 当前BSP、SDK版本满足依赖范围 | 拒绝安装，列出不满足项 |
| 生命周期状态 | 目标版本未进入“停止支持” | 拒绝安装，建议升级到受支持版本 |
只有四项全部通过，OTA包才进入下载与安装阶段。安装完成后，设备上报新的版本组合，版本矩阵和运维看板同步更新。这样，版本治理框架就从“文档规范”变成了“运行时约束”，真正防止了不兼容升级进入生产设备。