Capgo Semver 测试器

检查频道策略兼容性

原生基线版本

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

远程版本

分配给解析通道的捆绑版本。

应用上下文

平台

开发版

在模拟器上运行

通道设置

iOS

允许 iOS 设备更新

Android

允许 Android 设备更新

允许开发版

允许开发版更新

允许模拟器

允许模拟器设备更新

禁用原生下降

Prevents downgrading when running native code

禁用自动更新

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

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

"Native Baseline Version" 的含义是什么

Native Baseline Version 是将 native app 版本发送到 Capgo 的 native app 版本 version_build 当设备向更新服务器请求一个捆绑包时,在一个 Capacitor 应用中,该值可以来自 CapacitorUpdater.version 在 capacitor.config.*。如果该设置没有 package.json ，则插件会回退到 iOS 或 Android 的 native app 版本。不要假设它是你的

Capgo仍然使用 version_name __CAPGO_KEEP_0__ 还使用 major, minor, and patch , version_build.

Capacitor 配置

Set CapacitorUpdater.version 当你想让应用程序发送一个明确的版本号时。

优点： 易于保持iOS和Android构建的一致性。

缺点： 过时的配置如果你忘记在native发布前更新它，可能会报告错误的版本号。

原生应用程序版本

使用平台版本，如iOS CFBundleShortVersionString 或Android versionName.

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

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

目标版本

与远程版本、通道 SemVer 规则或元数据上传约束（如 --min-update-version）进行比较， --disable-auto-update metadata.

必须使用 防止发送需要更新的原生code的JavaScript到旧应用程序二进制文件。

Con: 缺点：

过于严格的规则可能会阻止有效的更新，直到通道或包元数据被调整。 version_build, 然后与您想要的远程包版本进行比较\n Capgo

為什麼Capgo使用語義化版本控制

传递的远程包版本进行比较。 is the most widely adopted versioning standard in software development. By using semver, Capgo ensures compatibility and safety when delivering live updates to your Capacitor apps.

Semver 标准允许 Capgo 精确了解每个更新包含的变化:

补丁更新 (1.0.0 → 1.0.1): 修复 bug，安全自动应用
次要更新 (1.0.0 → 1.1.0): 新功能，向后兼容
主要更新 (1.0.0 → 2.0.0): 破坏性更改，需要原生应用商店发布

这防止 Capgo 发送不兼容的更新到您的原生 code，保护您的用户免受崩溃的影响，并确保您的应用保持稳定。

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

虽然 Semver 对其核心格式严格，但您可以使用 预发布标识符 和 (And) 构建元数据:

🏷️ 构建元数据 (+) - "外观"层

1.2.0+20240315.142530

部署跟踪的时间戳

1.2.0+ui.refresh.dark-mode

UI更新的设计团队描述

1.2.0+build.4729.commit.a1b2c3d

CI/CD构建号和git提交

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

🔧 预发布标识符 (-) - 开发频道

1.3.0-β.1

Beta测试频道

1.3.0-热修支付

紧急修复分支

1.3.0-新API特性

特性分支测试

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

🎯 混合方法 - 最佳双方

1.3.0-rc.1+UI重设计.20240315

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

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

🚀 快速启动 / 快速开发

0.1.0 __CAPGO_KEEP_0__

0.2.0-beta.1 __CAPGO_KEEP_0__

0.2.0+ui.v2 __CAPGO_KEEP_0__

1.0.0 __CAPGO_KEEP_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 不同于规范所需的版本。请参阅我们的已报告的问题和上下文：Capgo营销网站。角色：短UI标签或导航项。见于：页面trust.astro。消息键`and`（And）。尝试的修复

从未合并

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

⚠ 降级保护使用全 semver 先后顺序，因此稳定 1.0.0 比 1.0.0-beta.2 新

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