Native + OTA 通道工作流

复制安装提示和本插件的完整 Markdown 指南。

一个常见的Capgo设置使用一个开发频道和一个 生产环境 频道。CI 将每个 OTA 包装上传到 dev, 然后促进到 production 当你准备好时。团队经常添加 --fail-on-incompatible 因此 CI 无法意外将实时更新推送到需要新本机code的频道。

本页面回答以下问题： 当你故意需要一个与频道当前本机包不兼容的包装时，

如果你需要了解为什么Capgo比较本机包的背景，请参阅本机兼容性。要查看自动选择 OTA 或Capgo Build 的完整 CI Branch，请参阅自动 OTA 或本机.

谁获得	典型上传	内部/ QA 版本
`dev`	每次 CI 推送的 JS (和意图的本机基线)	Channel
`production`	用户存储	仅在发布就绪时上传或推广

标题：每日OTA（保留标志）

终端窗口

npx @capgo/cli@latest bundle upload com.example.app \
  --channel production \
  --fail-on-incompatible \
  --auto-min-update-version

--fail-on-incompatible 阻止意外的原生漂移。 --auto-min-update-version 每次上传时都需要在此处填写此项（以下推荐策略）。如果您的频道尚未开通，请忽略此项，直到您切换。 metadata 上传前可选的CI门控： metadata 终端窗口 --auto-min-update-version 复制到剪贴板

有意原生升级（一旦使用过，请移除该标志）

npx @capgo/cli@latest bundle releaseType com.example.app --channel production
# → OTA      safe to upload with --fail-on-incompatible
# → native   stop; ship a native binary first (see below)

您

cannot cannot 上传一个需要新native code 的包 --fail-on-incompatible。这个标志是为了阻止这种情况。当一个插件、Capacitor 版本或其他native依赖项被故意改变时:

发布匹配的 native二进制文件 (App Store / Play Store, 或者 Capgo Build).
发布匹配的JS包而不 --fail-on-incompatible.
优先 --auto-min-update-version 使用带有channel的 metadata 策略，以便仍在使用旧二进制文件的设备不会在安装新应用之前接收到新包。
在baseline上传之后， --fail-on-incompatible 恢复到正常的 OTA CI (并保持) --auto-min-update-version 直到渠道保持在 metadata).

一次渠道：启用元数据门控
终端窗口
```
npx @capgo/cli@latest channel set production com.example.app --disable-auto-update metadata
```
重复 dev 如果该渠道也接收到有意的本机基线。在切换后，每次上传到该渠道都必须包含 --auto-min-update-version 或 --min-update-version.
在本机 OTA 基线中

将本机二进制文件发送
构建并提交包含新插件或本机更改的 iOS/Android 应用程序。直到用户安装该二进制文件，他们就不能安全地运行依赖于本机包的捆绑包。 --fail-on-incompatible)
上传匹配的 OTA 基线（不含）
```
npx @capgo/cli@latest bundle upload com.example.app \
  --channel production \
  --auto-min-update-version
```
此记录了该频道上的新本地包。后续的检查将使用该基线。 bundle releaseType / --fail-on-incompatible 恢复受保护的OTA上传

后续的JS-only发布将使用以下标志:

终端窗口

npx @capgo/cli@latest bundle upload com.example.app \
  --channel production \
  --fail-on-incompatible \
  --auto-min-update-version

常见问题

标题：可以保留 `--fail-on-incompatible` 并且仍然推送一个不兼容本机的捆绑包吗

不。上传的本机包如果与渠道的实时捆绑包不同，标志故意让命令失败。为了有意地升级本机版本，忽略该标志（并使用 --auto-min-update-version 当可以时）。

一次上传不带标志是正确的方法吗

是的。这是支持的方式来在您发布新二进制文件后推进渠道的本机基线。保留标志在其他OTA上传中，以便意外的本机漂移仍然会失败CI。

我应该先上传到开发环境，然后再上传到生产环境吗？ `dev` 首先， `production`?

是的，如果您的流程与此相符。运行相同的规则 每个频道:与目标频道当前在线内容的兼容性检查。推广或重新上传到 production 只有在 dev 看起来不错时， --fail-on-incompatible并使用本地基线上传（不

)在需要记录新本地包的每个频道上。

CI fails and Capgo does not ship that upload. That is the expected outcome. Either the change was accidental (fix the native packages and retry as OTA), or it was intentional (use the native path above).

哪个标志与哪个任务配对?

路径	时间	上传标志
OTA	仅使用JS；native包与渠道匹配	`--fail-on-incompatible` + `--auto-min-update-version` (如果渠道处于 `metadata`)
原生基线	新原生二进制文件+匹配的JS包	否 `--fail-on-incompatible`;保留 `--auto-min-update-version`

原生兼容性

原生包的Capgo如何检测包的漂移以及不兼容的设备意味着什么。

自动OTA或原生

Wire bundle releaseType 将其GitHub动作或GitLab导入CI中，以便CI选择正确的路径。

版本目标

context: Capgo解决方案营销页面。角色：部分或页面标题。见于：页面解决方案/版本目标.astro。消息键`solutions_version_targeting_title` (解决方案版本目标标题)。| Capgo解决方案营销页面。角色：短UI标签或导航项。见于：页面解决方案/版本目标.astro。消息键`solutions_version_targeting` (解决方案版本目标)。

CLI: bundle

__CAPGO_KEEP_0__:捆绑

上传、兼容性、releaseType和相关标志的参考资料。

如果您正在使用 Native + OTA Channel Workflow 与其保持安全的方式 Native Compatibility 用于包比较规则 Auto OTA 或 Native 用于 CI 分支版本目标页面/区域：Capgo 解决方案营销页面。角色：部分或页面标题。见于：page solutions/version-targeting.astro。消息键 `solutions_version_targeting_title` (解决方案版本目标标题)。| 页面/区域：Capgo 解决方案营销页面。角色：短 UI 标签或导航项。见于：page solutions/version-targeting.astro。消息键 `solutions_version_targeting` (解决方案版本目标)。 Capgo CLI bundle reference __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ 包引用