[具身智能-665]：ROS2 Humble / Jazzy 为什么不能合并为单一分支统一演进

先给出核心结论：Humble、Jazzy 是两套独立 ROS2 发行版（Distribution），不是同一个代码主干上的不同 tag；底层操作系统基线、ABI 冻结策略、迭代规则、维护目标完全隔离。强行合并在工程上不可行，同时违背 ROS2 官方发布规范（REP-2000/REP-2001）。

下面从五层由浅入深完整拆解，同时结合你关注的TogetheROS.Bot/RDK 开发场景补充工程推论。

一、基础概念澄清：ROS2 Distribution ≠ Git Tag

很多人会误解：

能不能像普通软件一样，一个 main 分支，打不同 tag 区分 Humble/Jazzy，共用一套代码？

ROS2 体系定义：

Distribution（发行版）= 一套锁定版本的完整软件包集合，包含：rclcpp、rmw、Nav2、RViz2、消息接口、第三方包、Deb 二进制包。 每一个发行版拥有独立源码分支、独立构建流水线（Buildfarm）、独立软件源。

• Rolling：开发主干（允许破坏性 API 变更）
• Humble：从 Rolling 某一时间点切出分支，冻结 API/ABI
• Jazzy：两年后再次从 Rolling 切出新分支，再次冻结 API/ABI

一旦分支切分完成，两个 LTS 分支只能单向 Backport（修复类补丁），不能双向合并新特性。

二、第一层硬性约束：底层操作系统基线完全不同（最不可逾越）

表格

关键后果：

1. 系统库 ABI 不兼容glibc、Boost、OpenCV、Qt、Python 大版本之间存在二进制断层；一套源码无法同时兼容两套系统环境。
2. 编译条件、头文件、语法校验标准不同GCC13 启用更多新 C++ 标准、更多严格警告；Qt5 与 Qt6 API 大量断裂（RViz2 最大痛点）。
3. ROS 官方规范 REP-2000 明确：一个 ROS 发行版仅能 Tier1 完整支持单一 Ubuntu LTS。 维护两套系统基线的编译、CI、二进制包构建成本极高，官方不会让一个分支同时兼容 22.04+24.04。

类比理解：你无法用同一套源码同时编译适配 Windows10 和 Windows11 的大型软件，底层依赖链差异过大。

三、第二层核心规则：发布后 API/ABI 冻结策略（最关键架构约束）

ROS2 核心铁律：

✅任何已经发布的 LTS 发行版内部，禁止引入破坏性 API/ABI 变更；只允许合并 Bug 修复、安全补丁（非破坏性修改）。

❌重大架构重构、接口调整、新特性，只能在 Rolling 主干开发，等待下一个新发行版分支切分时纳入。

推演：如果 Humble 和 Jazzy 合并到一条分支会发生什么？

1. Jazzy 要加入新特性（执行器重构、跨进程 LoanMessage、TypeDescription 改进），必然修改 rclcpp 内部接口；
2. 一旦修改接口，直接破坏 Humble 的 ABI 稳定性；所有基于 Humble 编译的机器人产品、第三方包会编译失败 / 运行崩溃；
3. 工业机器人厂商投入大量资金开发的产品，依赖 “LTS 版本 5 年内 ABI 稳定” 作为长期质保基础。

新功能 ≠ 可以向下兼容很多底层优化（执行器调度、DDS 消息序列化、零拷贝接口）无法做到兼容实现，只能打破接口。 因此官方设计：破坏性改动必须等待新发行版窗口，直接切出新分支。

四、第三层：通信层中间件（RMW/DDS）存在序列化断层

1. Humble 默认 CycloneDDS 0.9.x；Jazzy 升级 CycloneDDS；FastDDS 版本跨度更大（2.6 → 2.14）。
2. 自 Iron 开始引入REP-2011 Type Hash（RIHS01 类型哈希），消息序列化元数据发生变化。 👉Humble 节点无法直接和 Jazzy 节点原生互通，消息收发会匹配失败。

如果代码合并在同一分支，必须维护两套 RMW 适配逻辑，分支内充斥大量#ifdef ROS_DISTRO_JAZZY条件编译，代码急剧腐化，维护成本爆炸。

五、第四层：构建、打包、CI 流水线架构天然隔离

ROS 官方依靠Buildfarm 构建农场自动生成 apt 二进制 deb 包：

• Humble 软件源：ros-humble-xxx，为 Ubuntu22.04 编译
• Jazzy 软件源：ros-jazzy-xxx，为 Ubuntu24.04 编译

两套流水线：独立 CI 任务、独立测试矩阵、独立 rosdistro 软件清单。 若合并为单一代码分支：

• 每次提交必须同时在 22.04/24.04 双环境全量测试；CI 耗时翻倍；
• 无法区分补丁应当发布到哪个发行版；
• 第三方包维护者必须同时维护两套分支，社区负担巨大。

六、第五层：产品生命周期与商业诉求分层

行业存在两类大量并行存在的机器人项目：

1. 存量成熟产品：基于 Humble，生命周期到 2027，追求绝对稳定，拒绝任何底层改动；
2. 全新下一代项目：基于 Jazzy，想要新执行器、新零拷贝、更长支持周期（至 2029）。

如果强行合并为一条主线：

• 存量产品被迫接收底层架构改动，引入未知风险；
• 新项目被旧版本兼容性枷锁限制，无法引入现代化优化。

独立分支本质是 “风险隔离”：老项目稳定维护，新项目自由演进。

七、澄清一个常见误区：能不能通过条件编译，一套代码兼容两个版本？

技术上理论可行，但工程上极度不推荐，官方拒绝采用：

1. 代码充斥大量发行版判断宏，可读性、可维护性暴跌；
2. 任意修改都要双版本验证，BUG 引入概率大幅上升；
3. 无法保证 ABI 稳定，违背 LTS 设计初衷；
4. 第三方开发者、硬件厂商（如地平线 TROS.B）需要维护两套适配，没有简化任何工作量。

地平线 TogetheROS.Bot 现状正是这套逻辑的体现：锁定 Humble 分支开发，不会尝试同时兼容 Humble+Jazzy，避免两套底层系统、两套 ROS 接口带来的适配灾难。

八、整体演进流程极简梳理（看懂分支流转）

1. Rolling（main 开发分支）：所有新特性、架构修改、破坏性改动全部在这里开发
2. 发行时间点（偶数年 5 月）：从 Rolling切出新 LTS 分支（例如 2022 切 Humble，2024 切 Jazzy）
3. 新分支切出后：
   • Rolling 继续自由迭代，不受约束
   • Humble/Jazzy 各自冻结 API，仅接纳不破坏接口的 Bug 修复
4. 修复补丁流程：补丁先合入 Rolling；确认稳定后，选择性 Backport到 Humble/Jazzy（单向搬运，不反向合并功能）

plaintext

Rolling(main) ───────┬──────持续开发（新特性、破坏性修改） │ ┌──────────▼──────────┐ │ Humble（2022切出） │ 仅bug修复，无新功能 └─────────────────────┘ │ ┌──────────▼──────────┐ │ Jazzy（2024切出） │ 仅bug修复，无新功能 └─────────────────────┘

九、落地层面总结（结合 RDK+TROS.Bot 场景）

1. 不要幻想 “一套代码同时兼容 Humble+Jazzy” 做产品，底层系统、DDS、Qt、rclcpp 多重断层；
2. TROS.B 选择 Humble 作为基线，本质也是顺应这套 ROS 版本策略：锁定单一发行版，集中力量做软硬协同优化；
3. 技术选型决策：
   • 存量设备、RDK 项目：坚守 Humble，避免跨版本迁移成本；
   • 全新无硬件绑定、长期规划项目，评估 Jazzy，但要接受第三方驱动、硬件 SDK 适配滞后问题。