从版本号到工具链治理,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。官