Capgo Semver 测试器

检查频道策略与本地基准版本的兼容性

本地基准版本

本地版本发送到Capgo作为version_build，来自配置或本地应用元数据。

远程版本

分配给解析频道的包版本

应用上下文

平台

开发版

在模拟器上运行

频道设置

iOS

允许 iOS 设备更新

安卓

允许安卓设备更新

允许开发版

允许开发版更新

允许模拟器

允许模拟器设备的更新

在原生下禁用自动降级

在原生环境下运行时防止降级 code

禁用自动更新

主版本：阻止目标主版本大于版本号。允许 1.2.3 -> 1.9.0，阻止 1.2.3 -> 2.0.0。

输入两个语义版本以查看比较

什么是 "本机基线版本" 的含义

本机基线版本是设备向 Capgo 请求更新包时发送的本机应用程序版本。在一个 Capgo 应用程序中，这个值可以来自 version_build when the device asks the update server for a bundle. In a Capacitor app, that value can come from CapacitorUpdater.version 。如果没有这个设置，则插件会回退到 iOS 或 Android 的本机应用程序版本。不要假设它是你的 capacitor.config.*版本，除非你的构建将该值复制到配置或本机元数据中。 package.json __CAPGO_KEEP_0__ 还使用

Capgo version_name 知道哪个下载的包目前已安装。 major, minor频道semver策略，如 patch 和 version_build.

Capacitor config

__CAPGO_KEEP_0__ CapacitorUpdater.version 配置

设置当您希望应用程序发送一个明确的版本时。

优点： 易于在iOS和Android构建之间保持一致。

缺点：

过时的配置可能会在您忘记在原生发布前更新它时报告错误的版本号。 CFBundleShortVersionString 或 Android versionName.

优点: 与 TestFlight、App Store、Play Store 或内部测试中安装的二进制文件匹配。

缺点: 更改它需要原生构建，并且如果发布设置发生漂移，可能会在不同平台上有所不同。

Bundle 目标

与远程 Bundle 版本、渠道 Semver 规则或元数据上传约束（例如 --min-update-version该渠道必须使用 --disable-auto-update metadata.

优点: 防止向旧应用二进制文件发送需要更新原生 code 的 JavaScript。

缺点: 过于严格的规则可能会阻止有效的更新，直到渠道或 Bundle 元数据被调整为止。

对于这个测试者，输入设备发送的本地基线值 version_build然后与您希望Capgo传递的远程包版本进行比较。

为什么Capgo使用语义版本

语义版本语义版本是软件开发中最广泛采用的版本控制标准。通过使用semver，Capgo确保了在向您的Capacitor应用程序传递实时更新时兼容性和安全性。

语义版本标准允许Capgo了解每个更新中包含的具体变化:

补丁更新（1.0.0 → 1.0.1）： 修复bug，安全自动应用
次要更新（1.0.0 → 1.1.0）： 新功能，向后兼容
主要更新（1.0.0 → 2.0.0）： 破坏性更改，需要本机应用商店发布

防止Capgo向您的本机code发送不兼容的更新，保护您的用户免受崩溃的影响，并确保您的应用程序保持稳定。

超越基本版本控制：灵活的Semver策略

虽然semver对其核心格式非常严格，但您可以使用 预发布标识符 和 context:Capgo营销网站。角色：短UI标签或导航项。见于：页面trust.astro。消息键`and`（And）。:

构建元数据

1.2.0+20240315.142530

🏷️构建元数据（+）- "外观"层

部署跟踪的时间戳

1.2.0+ui.refresh.dark-mode

UI更新描述

1.2.0+build.4729.commit.a1b2c3d

重要提示： 构建元数据在版本顺序中被忽略 - 1.2.0+anything 等于 1.2.0 用于Capgo的更新逻辑.

🔧 预发布标识符（-）- 开发频道

1.3.0-beta.1

测试beta频道

1.3.0-hotfix.payment

紧急修复 branch

1.3.0-feature.newapi

功能分支测试

注意： 预发行版本具有较低的优先级 - 1.3.0-beta.1 < 1.3.0

🎯 混合方法 - 最好的两种世界

1.3.0-rc.1+ui.redesign.20240315

带有 UI 元数据和时间戳的发布候选版本

现实世界 Semver 使用案例 & 团队策略

🚀 启动 / 快速开发

0.1.0 - 第一次 MVP 发布

0.2.0-beta.1 - 新功能测试

0.2.0+ui.v2 - UI 设计元数据

1.0.0 - 生产就绪

使用 0.x.x 进行预 1.0 开发，设计跟踪元数据

🏢 企业 / 受管制

2.1.0 → 季度发布

2.1.1+sec.patch.cve2024 → 安全补丁跟踪

2.2.0-rc.1+audit.ready → 预审发布候选

严格遵循 Semver 的兼容性元数据

🎮 游戏/创意应用

1.0.0+season.winter.2024 → 季节性内容

1.1.0+event.halloween → 事件驱动功能

1.2.0+assets.hd.remaster → 资产更新

内容跟踪的创意元数据

⚡ 热修复策略

1.2.0 → 当前生产

1.2.1-hotfix.payment → 严重错误修复

1.2.1+urgent.20240315.1430 → 使用时间戳发布

预发布用于测试，用于部署跟踪的元数据

🌍 多平台战略

1.3.0+ios.optimized → iOS 专属优化

1.3.0+android.material3 → Android 设计更新

1.3.0+web.pwa.ready → PWA 能力

同一版本，平台特定的元数据

🔄 CI/CD 集成

1.4.0-alpha.1+build.123 → 自动预发布

1.4.0+deploy.staging.456 → 阶段性部署

1.4.0+prod.final.789 → 生产部署

自动化版本管理与部署元数据

💡 专业提示：

使用构建元数据（+）进行跟踪、时间戳或外观信息，这些信息不会影响兼容性
使用预发布标识符（-）为需要不同更新优先级的开发频道
结合两者以获得最大灵活性： 1.2.0-beta.1+ui.dark.theme.20240315
请记住：Capgo 遵循语义版本规则，规划您的频道策略

重要：Capgo 使用严格的语义版本

与npm 的语义版本实现不同，Capgo 严格遵循 SemVer 规范。npm 的 node-semver 有已知的规范偏差，这可能导致意外行为

例如，npm 将版本 1.0.0-alpha.1 与规范所需的方式查看我们的已报告的问题和（与）修复尝试那从未被合并的。

有效语义版本

1.0.0 ✓ 标准发布

2.1.3-alpha ✓ 预发布

1.0.0-beta.1 ✓ 带有数字的预发布

1.0.0+build.1 ✓ 构建元数据

1.0.0-rc.1+build.1 ✓ 完整版本

无效语义版本

v1.0.0 ✗ 不允许带有 'v' 的版本

1.0 ✗ 缺少修订版本

1.0.0.0 ✗ 版本部分过多

1.0.0- ✗ 空的预发布

1.0.0+ ✗ 空白构建元数据

Capgo 更新行为

✓ 次要策略允许在同一主次版本线上进行补丁级别的更改，例如 1.0.0 -> 1.0.1

✓ 补丁策略阻止 1.0.0 -> 1.0.1。它只允许后缀级别的更改，如 1.0.0-beta.1 -> 1.0.0-beta.2

✗ 主要策略阻止目标包装件的主版本号高于原生基线，例如 1.0.0 -> 2.0.0

⚠ 降级保护使用全面的语义版本号顺序，因此稳定 1.0.0 比 1.0.0-beta.2 新

本工具遵循官方语义版本规范与 npm 的实现不同