Capgo Semver 测试器

检查通道策略兼容性与原生基线版本（version_build）

Native Baseline Version

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

Remote Version

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

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

什么是"原生基线版本"

原生基线版本是发送到Capgo的原生应用程序版本 version_build when the device asks the update server for a bundle. In a Capacitor app, that value can come from CapacitorUpdater.version 在__CAPGO_KEEP_0__应用程序中，这个值可以来自 capacitor.config.*如果没有这个设置 package.json 插件会回退到iOS或Android的原生应用程序版本

Capgo still uses version_name __CAPGO_KEEP_0__仍然使用 major, minor来知道哪个下载的捆绑包当前安装了。支持通道语义版本策略，如 patch 与远程包进行比较 version_build.

Capacitor 配置

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

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

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

本机应用程序版本

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

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

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

目标包装

将其与远程包装版本、通道 SemVer 规则或上传约束（例如 --native-version.

优点： 防止向旧应用二进制发送需要更高原生 code 的 JavaScript。

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

为此测试者输入设备发送的原生基线值 version_build,然后将其与您希望 Capgo 交付的远程包装版本进行比较。

为什么 Capgo 使用语义版本控制

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

semver标准允许Capgo准确了解每个更新中包含的变化：

补丁更新（1.0.0 → 1.0.1）： 安全修复，适合自动应用
小版本更新（1.0.0 → 1.1.0）： 新功能，向后兼容
重大更新（1.0.0 → 2.0.0）： 破坏性更改，需要原生应用商店发布

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

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

虽然semver对其核心格式非常严格，但您可以使用__CAPGO_KEEP_0__扩展它以满足团队的需求 预发布标识符 和 🏷️ 部署跟踪时间戳 (+) - "外观"层:

部署跟踪时间戳

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

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

__CAPGO_KEEP_0__预发布候选版本,包含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 → 生产部署

自动化版本号与部署元数据

💡 Pro Tips：

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

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

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

例如，npm 将版本号 1.0.0-alpha.1 处理得与规范所需的方式不同。请参阅我们的已报告的问题和未被合并的修复尝试 that was never merged.

有效的语义版本号

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

✓ Patch 策略阻塞 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 的实现不同