跳过主要内容
Capgo logo

Capgo Semver Tester

检查渠道策略兼容性与本地基线版本

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

分配给解析渠道的包版本

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

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

本机基线版本是设备向 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_KEEP_0__

Capgo version_name 要知道哪个下载的包目前已安装。 Channel semver 政策，如 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使用语义版本

语义版本 是软件开发中最广泛采用的版本控制标准。 通过使用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发送不兼容的更新，保护你的用户免受崩溃的影响，并确保你的应用保持稳定。

Flexible Semver Strategies: Beyond Basic Versioning

虽然 Semver 对其核心格式非常严格，但您可以使用 pre-release identifiers 和 build metadata:

🏷️ Build Metadata (+) - The "Cosmetic" Layer

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
带有 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 → __CAPGO_KEEP_0__
2.2.0-rc.1+audit.ready → __CAPGO_KEEP_1__

严格遵循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 → 以时间戳发布

__CAPGO_KEEP_0__

🌍 多平台战略

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

✓ Minor 策略允许在同一主版本.次要版本线上进行补丁级别的更改，例如 1.0.0 -> 1.0.1
✓ Patch 策略阻止 1.0.0 -> 1.0.1。它只允许后缀级别的更改，如 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 的实现不同