Capgo Semver Tester

Capacitor 应用更新的语义版本兼容性检查

Local Version

Capgo 中安装的应用报告的版本，来自配置或原生应用元数据。

Remote Version

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

什么是"本地版本"

本地版本是设备询问更新服务器时已经在设备上的版本号。在一个Capacitor应用中，这个值可以来自 CapacitorUpdater.version 在 capacitor.config.*. 如果这个设置没有 package.json 提供，插件会回退到iOS或Android的原生应用版本号。不要假设它是你的

Capacitor config

__CAPGO_KEEP_0__配置 CapacitorUpdater.version 设置本地版本号时使用

优点： 在 iOS 和 Android 构建中保持一致性非常容易。

缺点： 如果忘记在原生发布之前更新配置文件，过时的配置文件可能会报告错误的版本。

原生应用版本

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

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

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

捆绑目标

与远程包版本、通道semver规则或上传约束进行比较，如 --native-version.

优点： 防止向旧应用程序二进制文件发送需要更新本机code的JavaScript。

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

为此测试器输入设备将报告的本地版本，然后将其与您希望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 对其核心格式严格，但您可以使用 预发布标识符 和 构建元数据:

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

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-beta.1

测试频道

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 redesign元数据

1.0.0 - 生产就绪

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

🏢 企业 / 受管制

2.1.0 → 季度发布

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

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

严格语义版本控制，遵守法规元数据

🎮 游戏 / 创意应用

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 → 正式发布

发布版本与发布元数据一起自动化

💡 Pro Tips：

使用构建元数据（+）进行跟踪、时间戳或不影响兼容性的外观信息
使用预发布标识符（-）进行需要不同更新优先级的开发通道
结合两者以获得最大灵活性： 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 与规范要求不一样。请参见我们的已报告问题和从未合并的修复尝试有效语义版本

✓ 标准发布

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.1.0)

✗ 重大更新需要原生应用商店发布 (1.0.0 → 2.0.0)

⚠ 预发布版本需要显式配置

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