Capgo Semver Tester

检查频道策略与原生基线的兼容性

原生基线版本

The native version sent to Capgo as version_build, from config or native app metadata.

远程版本

分发版本

应用上下文

平台

开发版

在模拟器上运行

频道设置

iOS

允许 iOS 设备更新

安卓

允许安卓设备更新

允许开发构建

允许开发构建的更新

允许模拟器

允许模拟器设备的更新

在原生环境下禁用自动降级

Prevents downgrading when running native 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.*__CAPGO_KEEP_0__ package.json 除非在构建中复制该值到配置或原生元数据中,否则使用版本号

Capgo仍然使用 version_name 要知道下载的包是当前安装的哪一个。 major, minor频道semver策略,如 patch ,和 version_build.

Capacitor config

__CAPGO_KEEP_0__配置 CapacitorUpdater.version 设置

当您希望应用程序发送一个明确的版本号时 优点:

易于在iOS和Android构建中保持一致。 缺点:

原生应用版本

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

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

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

Bundle目标

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

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

Con: 过于严格的规则可能会阻止有效的更新，直到频道或捆绑包元数据被调整。

为此测试器输入设备发送的本地基线值 version_build然后将其与您希望Capgo传递的远程捆绑包版本进行比较。

为什么Capgo使用语义版本

语义版本是软件开发中最广泛采用的版本控制标准。通过使用语义版本，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":"Page/area: Capgo marketing website. Role: Short UI label or navigation item. Seen in: page trust.astro. Message key `and` (And).":

构建元数据

1.2.0+20240315.142530

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

部署跟踪的时间戳

1.2.0+ui.refresh.dark-mode

1.2.0+build.4729.commit.a1b2c3d

CI/CD构建号和git提交

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

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

1.3.0-beta.1

测试频道

1.3.0-hotfix.payment

紧急修复支

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 → 严重bug修复

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 遵循 semver 先后顺序规则，因此请按照频道策略进行规划

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

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

例如，npm 对版本 1.0.0-alpha.1 与规范所需的方式不同。请参阅我们的已报告问题和 __CAPGO_KEEP_0__ __CAPGO_KEEP_0__

有效语义版本

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 更新行为

✓ 同一主版本号的次版本号允许 patch 变化，例如 1.0.0 -> 1.0.1

✓ 策略 patch 只允许修订号的后缀变化，如 1.0.0-beta.1 -> 1.0.0-beta.2

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

⚠ 降级保护遵循全面的语义版本规则，因此稳定版本 1.0.0 新于 1.0.0-beta.2

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