尧图网页设计 
BSP Versioning Release Management摘要：本文是 Zephyr BSP 系列的第 42 篇，系统讲解 BSP 的版本管理与发布机制。文章从"为什么 BSP 必须做 Versioning"出发，厘清 BSP 版本与 Zephyr 版本是两个独立维度，并给出公司 BSP 应版本化的 12 项核心内容。随后详细阐述 Semantic Versioning（MAJOR.MINOR.PATCH）的语义，以及 BSP 特有的依赖锁定问题——通过 Manifest、west.yml、Git Tag 实现可复现构建。文章还覆盖 Release Branch 设计、LTS 维护、Release Notes 与 Migration Guide 的写法、Release Gate 与 RC 流程，最终形成"版本矩阵"，帮助 FAE 与客户快速定位适用的 BSP 版本。到了第 42 篇，我们把前面20～41 篇学到的东西再往前推进一步：BSP 做出来以后，怎么管理版本？怎么发布？怎么让客户、FAE、应用工程师知道"这个 BSP 到底是哪一版"？这其实是公司 BSP 从"工程师能用"走向"公司可以长期维护"的关键一步。一、为什么 BSP 必须做 Versioning？假设公司有一个 SoC：Company SoC │ ├── Zephyr BSP │ ├── Vendor HAL │ ├── Board Support │ └── Toolchain / Build System第一版 BSP：BSP v1.0客户 A 使用：BSP v1.0 Zephyr4.2.0 SoC SDK1.3Board ABC Rev.A过了几个月，公司修复：UART bug SPI bug Clock bug于是发布：BSP v1.1客户 B 开始使用：BSP v1.1但是客户 A 的产品已经进入量产。这时候问题来了：客户 A 能不能直接升级到 v1.1？答案通常是：不能简单地说"可以"。因为 BSP 并不是一个单独文件。它可能同时涉及：Zephyr │ ├── SoC ├── HAL ├── Drivers ├── Devicetree ├── Kconfig ├── Linker ├── CMake └── Board所以 BSP Release 必须回答：这一版 BSP 到底包含什么？二、BSP Version ≠ Zephyr Version这是首先必须建立的概念。例如：Company BSP1.4.0完全可能基于：Zephyr4.2.0也可能：Company BSP1.5.0 └── Zephyr4.3.0因此：Zephyr version和：Company BSP version是两个不同维度。可以理解成：Company BSP │ ┌──────────┼──────────┐ │ │ │ Zephyr HAL Boards4.2.02.8.1 Rev.BBSP 是一个release bundle。三、公司 BSP 到底应该版本化什么？一个成熟 BSP 通常至少要管理：1. Zephyr version2. SoC support3. Vendor HAL4. Board support5. DeviceTree6. Kconfig7. Drivers8. Linker scripts9. Build system10. Toolchain requirements11. Documentation12. Validation results例如：Company BSP1.2.0 │ ├── Zephyr │ └──4.2.0 │ ├── HAL │ └──3.1.0 │ ├── SoC │ ├── CX32 │ └── CX32A │ ├── Boards │ ├── cx32_devkit │ └── cx32_evb │ ├── Drivers │ ├── uart │ ├── spi │ ├── i2c │ └── timer │ └── Validation ├── blinky ├── uart ├── spi └── samples所以：BSP Version 是整个 BSP 生态的版本，不只是某个 Git tag。四、推荐使用 Semantic Versioning公司 BSP 很适合使用：MAJOR.MINOR.PATCH也就是：1.4.2分别代表：1→ Major4→ Minor2→ Patch五、MAJOR 是什么？Major 表示：存在不兼容变化。例如：BSP1.x ↓ BSP2.0可能发生：DeviceTree binding 改变 Kconfig symbol 改变 Driver API 改变 Board name 改变 HAL API 改变 SoC architecture 改变例如旧版本：uart0: uart@40000000{compatible="company,uart";};新版：uart0:serial@40000000{compatible="company,uart-v2";};或者：CONFIG_COMPANY_UART改成：CONFIG_COMPANY_SERIAL这就可能影响大量 application。因此：1.x →2.0代表：用户需要认真检查 migration guide。六、MINOR 是什么？Minor 通常代表：增加功能，但尽量保持 backward compatibility。例如：BSP1.3.0增加：SPI driver I2C driver New EVB但原来的：UART GPIO Timer仍然工作。于是：1.2.0 ↓1.3.0可以表示：New features + Backward compatible例如：1.2.0 │ ├── UART ├── GPIO └── Timer1.3.0 │ ├── UART ├── GPIO ├── Timer ├── SPI ← new └── I2C ← new七、PATCH 是什么？Patch 通常用于：Bug fix例如：BSP1.3.0发现：UART RX interrupt bug修复后：BSP1.3.1通常不应该改变：DeviceTree API Kconfig interface Application API也就是说：1.3.0 ↓1.3.1应该尽量做到：same API same board same application只是：bug fixed八、但是 BSP 有一个特殊问题BSP 的版本号并不能解决全部问题。因为 BSP 同时依赖很多东西。例如：Company BSP1.4.0 Zephyr Zephyr BSP: 42-BSP版本管理 and发布
BSP Versioning Release Management摘要：本文是 Zephyr BSP 系列的第 42 篇，系统讲解 BSP 的版本管理与发布机制。文章从"为什么 BSP 必须做 Versioning"出发，厘清 BSP 版本与 Zephyr 版本是两个独立维度，并给出公司 BSP 应版本化的 12 项核心内容。随后详细阐述 Semantic Versioning（MAJOR.MINOR.PATCH）的语义，以及 BSP 特有的依赖锁定问题——通过 Manifest、west.yml、Git Tag 实现可复现构建。文章还覆盖 Release Branch 设计、LTS 维护、Release Notes 与 Migration Guide 的写法、Release Gate 与 RC 流程，最终形成"版本矩阵"，帮助 FAE 与客户快速定位适用的 BSP 版本。到了第 42 篇，我们把前面20～41 篇学到的东西再往前推进一步：BSP 做出来以后，怎么管理版本？怎么发布？怎么让客户、FAE、应用工程师知道"这个 BSP 到底是哪一版"？这其实是公司 BSP 从"工程师能用"走向"公司可以长期维护"的关键一步。一、为什么 BSP 必须做 Versioning？假设公司有一个 SoC：Company SoC │ ├── Zephyr BSP │ ├── Vendor HAL │ ├── Board Support │ └── Toolchain / Build System第一版 BSP：BSP v1.0客户 A 使用：BSP v1.0 Zephyr4.2.0 SoC SDK1.3Board ABC Rev.A过了几个月，公司修复：UART bug SPI bug Clock bug于是发布：BSP v1.1客户 B 开始使用：BSP v1.1但是客户 A 的产品已经进入量产。这时候问题来了：客户 A 能不能直接升级到 v1.1？答案通常是：不能简单地说"可以"。因为 BSP 并不是一个单独文件。它可能同时涉及：Zephyr │ ├── SoC ├── HAL ├── Drivers ├── Devicetree ├── Kconfig ├── Linker ├── CMake └── Board所以 BSP Release 必须回答：这一版 BSP 到底包含什么？二、BSP Version ≠ Zephyr Version这是首先必须建立的概念。例如：Company BSP1.4.0完全可能基于：Zephyr4.2.0也可能：Company BSP1.5.0 └── Zephyr4.3.0因此：Zephyr version和：Company BSP version是两个不同维度。可以理解成：Company BSP │ ┌──────────┼──────────┐ │ │ │ Zephyr HAL Boards4.2.02.8.1 Rev.BBSP 是一个release bundle。三、公司 BSP 到底应该版本化什么？一个成熟 BSP 通常至少要管理：1. Zephyr version2. SoC support3. Vendor HAL4. Board support5. DeviceTree6. Kconfig7. Drivers8. Linker scripts9. Build system10. Toolchain requirements11. Documentation12. Validation results例如：Company BSP1.2.0 │ ├── Zephyr │ └──4.2.0 │ ├── HAL │ └──3.1.0 │ ├── SoC │ ├── CX32 │ └── CX32A │ ├── Boards │ ├── cx32_devkit │ └── cx32_evb │ ├── Drivers │ ├── uart │ ├── spi │ ├── i2c │ └── timer │ └── Validation ├── blinky ├── uart ├── spi └── samples所以：BSP Version 是整个 BSP 生态的版本，不只是某个 Git tag。四、推荐使用 Semantic Versioning公司 BSP 很适合使用：MAJOR.MINOR.PATCH也就是：1.4.2分别代表：1→ Major4→ Minor2→ Patch五、MAJOR 是什么？Major 表示：存在不兼容变化。例如：BSP1.x ↓ BSP2.0可能发生：DeviceTree binding 改变 Kconfig symbol 改变 Driver API 改变 Board name 改变 HAL API 改变 SoC architecture 改变例如旧版本：uart0: uart@40000000{compatible="company,uart";};新版：uart0:serial@40000000{compatible="company,uart-v2";};或者：CONFIG_COMPANY_UART改成：CONFIG_COMPANY_SERIAL这就可能影响大量 application。因此：1.x →2.0代表：用户需要认真检查 migration guide。六、MINOR 是什么？Minor 通常代表：增加功能，但尽量保持 backward compatibility。例如：BSP1.3.0增加：SPI driver I2C driver New EVB但原来的：UART GPIO Timer仍然工作。于是：1.2.0 ↓1.3.0可以表示：New features + Backward compatible例如：1.2.0 │ ├── UART ├── GPIO └── Timer1.3.0 │ ├── UART ├── GPIO ├── Timer ├── SPI ← new └── I2C ← new七、PATCH 是什么？Patch 通常用于：Bug fix例如：BSP1.3.0发现：UART RX interrupt bug修复后：BSP1.3.1通常不应该改变：DeviceTree API Kconfig interface Application API也就是说：1.3.0 ↓1.3.1应该尽量做到：same API same board same application只是：bug fixed八、但是 BSP 有一个特殊问题BSP 的版本号并不能解决全部问题。因为 BSP 同时依赖很多东西。例如：Company BSP1.4.0 Zephyr