跳过主要内容
Capgo logo

Capgo Semver 测试器

__CAPGO_KEEP_0__ Semver 测试器检查渠道策略兼容性与原生基线发送的版本_build

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

分发给解析渠道的包版本

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

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

本机基线版本是设备向 Capgo 请求更新服务器的包时发送的本机应用程序版本。在一个 Capgo 应用程序中，这个值可以来自 version_build Capacitor CapacitorUpdater.version 在该设置未被设置时，插件将回退到 iOS 或 Android 原生应用版本。请勿假设它是您的版本，除非您的构建将该值复制到配置或原生元数据中。 capacitor.config.*. If that setting is not present, the plugin falls back to the native app version from iOS or Android. package.json 除非您的构建将该值复制到配置或原生元数据中，否则请勿假设它是您的版本。

Capgo still uses version_name __CAPGO_KEEP_0__ still uses major, minor为了知道哪个下载的包当前已安装， patch Channel semver 政策，例如 version_build.

Capacitor config

将远程包与 CapacitorUpdater.version __CAPGO_KEEP_0__

配置 设置

Con： 如果忘记在原生发布前更新它，会导致 stale config 报告错误的版本。

原生应用版本

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

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

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

打包目标

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

Pro： 防止发送需要更高版本本机code的JavaScript代码到旧的应用程序二进制文件。

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

为此测试器输入设备发送的本机基线值 然后与您希望__CAPGO_KEEP_0__传递的远程捆绑版本进行比较。 version_build为什么Capgo使用语义版本控制

Why Capgo uses Semantic Versioning

是软件开发中最广泛采用的版本控制标准。 通过使用semver，__CAPGO_KEEP_0__确保了在向您的__CAPGO_KEEP_1__应用程序传递实时更新时兼容性和安全性。 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.

The semver standard allows Capgo to understand exactly what changes are included in each update:

  • 修复bug，安全自动应用 小版本更新（1.0.0 → 1.1.0）：
  • 修复bug，安全自动应用 新功能，向后兼容
  • 重大更新（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
紧急修复支
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 与规范所需的方式不同。请参见我们的 已报告的问题 并且 未被合并的修复尝试。 有效语义版本

✓ 标准发布

1.0.0 ✓ 预发布
2.1.3-alpha ✓ 带有数字的预发布
1.0.0-beta.1 ✓ 构建元数据
1.0.0+build.1 ✓ 完整版本
1.0.0-rc.1+build.1 无效语义版本

✗ 不允许带有 'v' 的开头

v1.0.0 protectedTokens
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
⚠ 降级保护遵循全面的 SemVer 优先顺序，因此稳定版本 1.0.0 比 1.0.0-beta.2 新

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