PaceVer：为移动应用量身定制的版本控制新范式

背景

在软件工程中，语义化版本控制（Semantic Versioning，简称 SemVer）一直是库（Library）、包（Package）和 API 版本管理的黄金标准。SemVer 的核心逻辑在于通过 MAJOR.MINOR.PATCH 三位数字来传达代码变更对兼容性的影响：主版本号代表不兼容的 API 修改，次版本号代表向后兼容的功能新增，修订号代表向后兼容的问题修正。

然而，移动应用（Mobile Apps）的分发机制与传统的软件库有着本质的区别。库通常只有一个发布渠道，开发者只需关心“契约是否被破坏”。但基于 React Native、Expo 或类似框架开发的移动应用，实际上拥有两个并行且速度不同的发布渠道：

1. 原生渠道（Native Channel）：涉及原生代码、新依赖、SDK 升级或权限变更。这类更新必须生成新的二进制文件，通过 App Store、Google Play Store 或 TestFlight 等分发渠道发布。这个过程缓慢，受限于应用商店的审核流程，且一旦发布很难瞬间回滚。
2. 空中下载技术渠道（OTA Channel）：涉及 JavaScript 代码、样式表、内容或当前运行时环境内的资源更新。这类更新可以直接推送到用户设备上，无需经过应用商店审核，几分钟内即可生效。

SemVer 的 MAJOR.MINOR.PATCH 结构无法区分这两种截然不同的发布路径。它只描述了“改了什么”，却忽略了移动开发中至关重要的“怎么改”以及“如何到达用户手中”。后者直接决定了审核延迟、 rollout 速度和回滚能力。PaceVer 正是为了解决这一痛点而诞生，它将“发布节奏”本身作为版本号的语义核心。

核心内容

PaceVer 提出了一种替代 SemVer 的版本号规范，专为移动应用设计。其版本号格式为 MARKETING.NATIVE.OTA（例如 1.4.12），每一位数字都有明确的物理意义和发布节奏指向。

1. 版本号结构解析

• MARKETING（营销号）：

  • 定义：这是完全由团队自由定义的数字。它可以用于标记时代更迭、新年、重大重新设计、品牌重塑、重写或里程碑事件，也可以长期保持不变。
  • 语义：它不携带任何兼容性承诺。如果团队希望向用户或内部传达某次变更的“规模”或“重要性”，这是唯一的信号位。
  • 预发布阶段：0 保留给预发布阶段。团队应在发布第一个稳定版本时将此位设为 1（即 1.0.0）。
  • 约束：在项目生命周期内，MARKETING 必须单调非递减。

• NATIVE（原生号）：

  • 定义：每当发布需要安装新二进制文件的版本时，此数字递增。
  • 触发条件：任何 OTA 无法交付的变更，包括原生代码修改、新依赖项、SDK/运行时升级、权限变更或编译配置更改。
  • 节奏：慢。受限于应用商店审核流程。
  • 联动规则：当 NATIVE 递增时，OTA 必须重置为 0，因为新的原生构建开启了全新的 OTA lineage（谱系）。

• OTA（空中更新号）：

  • 定义：每当向现有构建推送空中更新时，此数字递增。
  • 触发条件：JavaScript 代码、样式、内容、资产等在当前运行时内可交付的变更。
  • 节奏：快。几分钟内生效，无需商店审核。
  • 限制：OTA 更新必须与其目标原生构建兼容，不得推送给未为其生产的原生构建。

2. 版本递增与重置规则

PaceVer 强调版本号的单调递增性，但允许局部重置以反映发布谱系的改变：

• NATIVE 递增：强制将 OTA 重置为 0。
• MARKETING 递增：建议（SHOULD）同时将 NATIVE 和 OTA 重置为 0。例如，一次重大重新设计可能使版本从 1.6.2 变为 2.0.0。
• 替代方案：团队也可以选择让 NATIVE 和 OTA 在 MARKETING 递增时继续累加（例如从 1.6.2 变为 2.6.2），但必须选定一种约定并保持一致。

3. 运行时版本组成

应用报告的版本号应在运行时动态组成：

• MARKETING 和 NATIVE 由已安装的二进制文件固定决定。
• OTA 反映当前应用的空中更新版本；若未应用任何 OTA 更新，则为 0。
• 原生构建中捆绑的 JavaScript 和资源被视为基线，不计入 OTA 1。

4. 优先级与比较

版本优先级的比较逻辑与 SemVer 类似，从左至右数值比较： 1.2.0 < 1.2.7 < 1.3.0 < 2.0.0

5. 多平台一致性

PaceVer 要求所有平台（iOS, Android 等）保持步调一致。

• MARKETING、NATIVE 和 OTA 是项目级的全局数字，而非按平台追踪。
• 当 NATIVE 递增时，必须向所有分发渠道发布新的二进制文件，即使某些平台没有功能变更。这确保了所有平台共享相同的原生运行时，从而使得单个 OTA 更新可以统一应用于所有平台，版本号唯一。

6. 适用范围与边界

• 适用：面向用户的应用客户端，通过原生渠道和 OTA 渠道分发。
• 不适用：库、包或向其他软件暴露程序化契约的 API。这些仍应使用 SemVer。

7. 标识符与元数据

• 可以在 OTA 后附加标识符。连字符 - 引入预发布标识符（如 1.4.0-rc.1），加号 + 引入构建元数据（如 1.4.0+ios）。
• PaceVer 不赋予这些后缀特定的渠道或节奏含义，解释由团队自行决定。
• 在确定优先级时，构建元数据必须被忽略。

8. 初始版本与稳定化

• 项目应从 0.1.0 开始，其中 MARKETING 0 标记预发布时代。
• 当团队认为应用稳定并准备向公众发布时，将 MARKETING 增至 1。
• 遵循推荐的重置规则，第一个稳定版本为 1.0.0；若不重置，则延续之前的数字（如 0.5.3 变为 1.5.3）。

关键要点

• 语义重构：PaceVer 将版本号从“兼容性承诺”转向“发布节奏描述”。2.5.0 → 2.5.3 表示通过 OTA 快速发布，而 2.5.3 → 2.6.0 表示等待商店审核的新原生二进制包。
• 商店合规性：应用商店通常要求三个整数的营销版本号。PaceVer 巧妙地将 OTA 号在运行时动态叠加，而在商店提交时，二进制文件携带的营销版本为 MARKETING.NATIVE.0（OTA 固定为 0），完美契合商店规则。
• 工具兼容性：PaceVer 保持了 X.Y.Z 的字符串形式和从左至右的优先级比较逻辑，现有的 SemVer 排序和比较工具无需修改即可正常工作。
• 单一真理源：通过强制所有平台共享相同的 NATIVE 构建和 OTA 编号，消除了多平台开发中常见的版本碎片化问题。
• 灵活性：MARKETING 号完全由团队定义，可用于标记任何非技术性的里程碑（如新年、品牌重塑），而不必受限于 API 兼容性。

意义与影响

PaceVer 的提出标志着移动应用版本管理从“静态契约”向“动态交付”