25.12 SP1的manifest上有的组件构建版本号比组件代码版本差一

[yangbo (HKZY_YangBo)]

https://gitcode.com/openUBMC/manifest/blob/br_release_openUBMC2512_20261231_LTS_SP1/build/subsys/hardware.yml

https://gitcode.com/openUBMC/pcie_device/blob/br_release_openUBMC2512_20261231_LTS_SP1/mds/service.json

https://gitcode.com/openUBMC/general_hardware/blob/br_release_openUBMC2512_20261231_LTS_SP1/mds/service.json

https://gitcode.com/openUBMC/power_mgmt/blob/br_release_openUBMC2512_20261231_LTS_SP1/mds/service.json

---

类似的有hica，这种manifest的版本更新是统一管理，还是说hardware和framework单独管理哇？

https://gitcode.com/openUBMC/manifest/blob/br_release_openUBMC2512_20261231_LTS_SP1/build/subsys/framework.yml

https://gitcode.com/openUBMC/hica/blob/br_release_openUBMC2512_20261231_LTS_SP1/mds/service.json

[ubmc_assistant (openUBMC_Assistant)]

答案内容由AI生成，仅供参考：

五、总结：这是正常现象，体现工程严谨性

问题	回答
为什么 manifest 版本比组件代码低？	因为 manifest 是受控的“产品配方”，需验证后才升级，体现稳定性优先原则。
是 bug 吗？	不是，是标准做法。
如何更新？	由版本负责人在 hardware.yml 或 framework.yml 中手动更新版本号，并提交测试。
是统一管理还是分模块管理？	分模块管理：hardware.yml 和 framework.yml 可独立更新，由 manifest.yml 统一集成。

最佳实践建议：
若您在定制开发中遇到依赖问题，应以 manifest 中声明的版本为准进行适配，而非直接使用组件最新代码，以确保整体系统的兼容性与稳定性。

点击此处查看详细分析解答

openUBMC 25.12 SP1 版本中组件版本不一致问题分析

根据您提供的图片和代码对比信息，openUBMC 25.12 SP1（分支：br_release_openUBMC2512_20261231_LTS_SP1）的 manifest 仓库中，确实存在 组件在 manifest.yml 中声明的版本号低于其实际代码仓库中 service.json 定义的版本号 的现象。

这并非异常或错误，而是由 openUBMC 的构建和版本管理机制所决定的。下面将详细解释原因和管理策略。

---

一、问题确认：版本不一致的实例

您提供的多个截图清晰地展示了版本差异：

组件	manifest 中声明的版本	组件代码中 service.json 版本	差异
pcie_device	1.71.0（在 hardware.yml）	1.71.1	manifest 低1个补丁版本
general_hardware	1.91.2	1.91.3	manifest 低1个补丁版本
power_mgmt	1.71.0	1.71.1	manifest 低1个补丁版本
hica	1.70.14（在 framework.yml）	1.70.15	manifest 低1个补丁版本

这表明 manifest 中的版本并未实时同步到最新代码版本。

---

二、原因解析：为何存在这种“滞后”？

该现象的核心原因在于：manifest 的版本管理机制是中心化、受控的，而非实时拉取最新代码。

1. Manifest 是“产品级构建策略”的定义文件

• manifest 仓库（如 manifest/build/subsys/hardware.yml 或 framework.yml）本质上是“产品配方”文件。
• 它的作用是锁定一组经过验证、兼容、稳定的组件版本组合。
• 即使某个组件（如 hica）代码仓库发布了 1.70.15，manifest 不会自动采用，除非经过测试并显式更新。

2. 版本更新需经过“验证流程”

• 开发团队不会随意将最新的组件版本纳入 manifest。
• 新版本必须经过：
  • 自动化测试（CI）
  • 兼容性验证
  • 联调测试
  • 安全扫描
• 只有通过后，才会在 manifest 中手动或通过流水线更新版本号。

因此，manifest 中版本低于组件代码版本，是一种有意为之的稳定策略，而非疏漏。

---

三、manifest 版本管理策略：统一管理还是分模块管理？

从您提供的 hardware.yml 和 framework.yml 文件结构来看，openUBMC 采用的是 分模块、分层管理 的策略：

管理方式：分层分模块锁定

文件	作用	管理方式
hardware.yml	管理硬件相关组件（如 pcie_device, storage, power_mgmt）	模块化独立管理
framework.yml	管理框架级组件（如 hica, devmon, component_drivers）	模块化独立管理
manifest.yml（总控）	汇总并引用各 yml 文件，作为整包构建入口	统一协调

示例：manifest.yml 可能这样引入：

imports:
  - file: subsys/hardware.yml
  - file: subsys/framework.yml

更新机制

• 允许单独更新某一模块的组件版本，例如只升级 framework.yml 中的 hica，而不影响 hardware.yml。
• 由专人（如版本经理）统一协调各模块的版本集成。
• 常通过批量提交（如 yaoshun1 批量更新组件版本）进行同步。

---

四、版本更新流程（基于上下文推断）

结合知识库和文档内容，典型更新流程如下：

1. 组件开发完成并发布新版本
   • 开发者修改组件的 service.json 中 version（如从 1.71.0 → 1.71.1）。
2. 组件通过 bingo build 构建成 Conan 包
   • 包名为：component_name/1.71.1@openubmc/stable
3. 版本管理员审查并更新 manifest
   • 修改 hardware.yml 或 framework.yml 中对应组件版本。
4. 整包构建与验证
   • 执行 bingo build，使用 manifest 定义的版本拉取依赖。
5. 发布 SP1 新固件包

---

五、总结：这是正常现象，体现工程严谨性

问题	回答
为什么 manifest 版本比组件代码低？	因为 manifest 是受控的“产品配方”，需验证后才升级，体现稳定性优先原则。
是 bug 吗？	不是，是标准做法。
如何更新？	由版本负责人在 hardware.yml 或 framework.yml 中手动更新版本号，并提交测试。
是统一管理还是分模块管理？	分模块管理：hardware.yml 和 framework.yml 可独立更新，由 manifest.yml 统一集成。

最佳实践建议：
若您在定制开发中遇到依赖问题，应以 manifest 中声明的版本为准进行适配，而非直接使用组件最新代码，以确保整体系统的兼容性与稳定性。

---

如需查看当前 manifest 所有组件的版本锁定详情，可检查：

manifest/build/subsys/hardware.yml
manifest/build/subsys/framework.yml

[xuhaijun]

manifest.yml描述组件集成策略，它决定了要集成哪些组件、组件版本、组件特性。只要组件功能没问题，manifest.yml可以集成一个组件的任一版本，所以没有要求manifest.yml中描述的组件版本必须是组件发布的最新版本。