Zephyr 3.7固件交接：应用版本与构建标识分别回答什么

同一个应用版本交付了两次固件，测试人员发现表现不同，开发人员却说版本号没有变化。这里未必是谁记错了，而是发布命名与构建身份承担不同任务。交接材料需要同时回答“这是什么版本”和“这份产物来自哪次构建”，不能把两个问题都交给一个短字符串。

Zephyr 3.7.0的应用版本管理文档说明，应用在根目录的VERSION文本文件中定义版本字段，该目录也放置应用的CMakeLists.txt。构建系统处理这些字段，并向代码及构建配置提供相应信息。本文讨论的是固定发布版文档，不把页面导航中的latest文字当作所用工程已经升级到最新版本。

文档列出的应用版本字符串来自主版本、次版本、补丁级别等字段，扩展字符串还可包含额外信息。APP_BUILD_VERSION则来自应用仓库的git describe结果。前者表达项目给版本起的名字，后者帮助关联仓库状态；如果只在交付单中保留一个名称，就可能无法区分同名版本下的不同构建背景。

为固件整理记录时，可以将应用版本、代码提交、实际构建标识与产物文件对应放置，再附上构建配置、目标板及工具链信息。这里是本文的交接资料建议，不代表这些字段都由VERSION文件自动保存。自动生成了版本头文件，也不意味着项目已经自动完成全部构建追溯。

尤其要区分“能找到代码”与“能重现相同二进制”。Git标识提供一个入口，但文档中的版本机制没有替读者验证依赖、配置、工具链和产物是否完全一致。若需要比较两份固件，真实文件及其校验值应另行留存；本文没有执行构建、计算实际交付文件的校验值或证明可重现构建。

当界面显示相同版本而行为不同时，可以先核对交付记录是否指向同一产物，再查看代码及配置是否一致，而不是立即改动版本字符串来掩盖差异。问题记录也应保留观察条件，避免把某块板上的现象扩写成该版本在所有硬件上都存在同一问题。

官方页面还讨论支持的引导加载器场景，但这里不延伸为签名、升级或刷写操作指南。版本信息被包含在镜像中，与升级过程是否成功是两层证据。清楚标记版本、构建和产物之间的关系，才能让后续验证有可定位的对象，而不是只剩下一句“用的是同一版本”。