当发布重大版本时
版本管理可能很难，通常您希望在用户出现重大变化时发送重大更新。
但版本号不是为此而设计的，应用商店版本号与原生版本号不同。
原生版本用于管理破坏性更改的 code
例如，在IOS中，IOS 16是 store version 的，但code版本是 20A5283p （他们似乎没有使用SemVer）
现在很明显我们不混淆它们，并使用它们的目的！
重大发布
在您的Capacitor应用中，当发生破坏性更改时，需要进行重大发布。 例如，新IOS目标（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 文件中设置。
您可以通过在
capacitor.config.json文件 中设置版本键来覆盖此行为
文件
Will be uses by Capgo to compare to JavaScript version and find Major upgrade
Android android/app/build.gradle 将由__CAPGO_KEEP_0__用于与JavaScript版本进行比较并找到重大升级 defaultConfig.versionName
在Android中，变量在您的项目中设置，
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时。
所有下一个实时更新在Capgo 2.2.4 不会将此版本发送给用户， 1.2.3 仅在 2.2.3 版本中才会发送。
如果您遵循此模式，无需担心，所有问题都已得到处理。
如果我不遵循这个
在这种情况下，这意味着您必须将新应用程序（Capacitor 4）发送到苹果和谷歌，但不要发送到Capgo。
然后您必须等待100%的用户都有应用程序，或者至少90%，这将花费几个月的时间，可能会更长。
在此期间，您不能发送任何更新Capgo，因为老用户无法获得新版本。 您没有选择只发送更新给某些用户的方法。
Keep going from How to release major version in capgo
如果您正在使用 How to release major version in capgo 来规划回滚和版本控制，连接它 回滚 关于回滚的实现细节 版本目标 关于版本目标的实现细节 更新行为 关于更新行为的实现细节 打包 关于打包的实现细节 Capgo 实时更新 关于Capgo 实时更新的产品工作流程
