从版本号到工具链治理，SAPUI5 Versioning 背后的工程纪律

最近做 Fiori Elements 应用时，经常会遇到一个看似很小、实际很容易引发连锁问题的细节，SAPUI5 到底应该锁定哪个版本。很多团队一开始只关心页面能不能跑起来，等到后面出现控件行为差异、样式细节变化、UI5 CLI 构建失败、Fiori Launchpad 和本地预览不一致时，才意识到 SAPUI5 versioning 不是一个单纯的数字问题，而是一整套运行时、工具链、补丁策略和系统景观治理规则。

SAPUI5 从早期版本开始就强调运行时和工具链之间的版本一致性。以 SAPUI5 1.6 之后的规则来看，SAPUI5 core/runtime 和 SAPUI5 tools 存在非常紧密的耦合关系。在同一个运行系统中，两者需要保持相同的 major version 和 minor version。举个简单的版本关系，SAPUI5 core/runtime 1.x.1 可以和 SAPUI5 tools 1.x.2 一起工作，因为 major 和 minor 都是 1.x，只是 patch 不同。可是 SAPUI5 core/runtime 1.x.1 不应该和 SAPUI5 tools 1.y 搭配，因为 minor version 已经不一致。这个规则的目的很朴素，运行时解释应用，工具链生成应用，两边如果对模块、控件元数据、预加载资源、构建产物的理解不一致，应用就会进入一种很难排查的灰色状态。

回到版本号这块，SAPUI5 使用三段式版本标识。官方当前文档仍然说明，SAPUI5 使用三个数字组成的版本号，例如 1.71.22，其中第一段代表 release number，也就是 major version，第二段代表 version number，也就是 minor version，第三段代表 patch number。官