发布大版本时
版本管理可能很复杂，通常在出现重大变更时，你会希望向用户推送一个 Major 更新。
但版本号的设计初衷并非如此，App Store 的版本与 Native 版本是不同的。
Native 版本旨在管理以下方面的破坏性变更： code
例如，在 iOS 中，iOS 16 是 store version Apple 的版本，但 code 的版本是 20A5283p （他们似乎并不使用 SemVer）
现在清楚了，我们不会混用它们，而是让它们各司其职！
主版本发布
在你的 Capacitor 应用中，当发生破坏性变更时，就需要发布主版本。 例如，新的 iOS target（15 到 16）、Capacitor 的新版本（3 到 4），或你使用的插件（1.2 到 2.0）升级到了主版本。
这意味着所有工具链都必须对齐，以处理这一破坏性变更。
这就是为什么 Capgo 遵循这一机制。
如果你发布主版本，Capgo 就不会将其发送给尚未从应用商店安装该版本的用户。
此行为可以自定义。你可以了解更多信息，请访问 这里
版本
在哪里找到要比较的版本（Capgo）
iOS
Capgo 将使用此项与 JavaScript 版本进行对比，以识别大版本升级
在 iOS 中，该变量在此处进行设置 ios/App/App/Info.plist 对应键下CFBundleShortVersionString 或 ios/App/App.xcodeproj/project.pbxproj 对应键下 MARKETING_VERSION 如果 MARKETING_VERSION 已在您的中设置 Info.plist 文件。
你可以通过在以下位置设置 version 键来覆盖此行为：
capacitor.config.json文件 文档见此处
Android
Capgo 将以此版本与 JavaScript 版本进行对比，从而识别大版本升级
在 Android 中，该变量在项目的此处设置 android/app/build.gradle 对应键下 defaultConfig.versionName
你可以通过在以下位置设置 version 键来覆盖此行为：
capacitor.config.json文件 文档见此处
JavaScript
Capgo 将以此版本与 Native 版本进行对比，从而识别大版本升级
在 JavaScript 中，该变量在项目的此处设置 package.json 对应键下 version
示例
您当前的 Ionic 应用版本为 1.2.3 版本为 Capacitor 3
您正在升级到 capacitor 4。
您需要将版本号升级为 2.2.3，随后所有包都将包含 Capgo，并提示此重大变更。
当您将此版本发布到 Capgo 和 App Store 时。
后续所有 live update 在 Capgo 中 2.2.4 将不会发送给使用 1.2.3 版本的用户。仅针对 2.2.3 版本进行发送。
遵循此模式，您无需担心，一切都会处理妥当。
如果不这样做
在这种情况下，这意味着你必须通过 Capacitor 4 向 Apple 和 Google 提交新应用，但无法通过 Capgo 进行更新。
然后你必须等待，直到 100%（或者至少 90%）的用户都安装了新版应用，这可能需要好几个月的时间。
在此期间，你无法通过 Capgo 发送任何更新，因为旧版本用户无法获取新版本。 你也没有办法选择仅让部分用户接收更新。
继续阅读：如何在 capgo 中发布大版本
如果你正在使用 如何在 capgo 发布大版本 要规划回滚和版本控制，请将其与 回滚 有关 Rollbacks 的实现细节， 版本定向 有关 Version Targeting 的实现细节， 更新行为 有关 Update Behavior 的实现细节， bundle 有关 bundle 的实现细节，以及 Capgo Live Updates 有关 Capgo Live Updates 的产品工作流。
