破坏性更改

本文档解释了如何使用版本通道来处理应用程序中的破坏性更改。这一方法允许您维护应用程序的不同版本，同时确保用户接收兼容的更新。

示例场景

假设您有：

• 应用程序版本 1.2.3（旧版本）- 使用生产通道
• 应用程序版本 2.0.0（新版本，包含破坏性更改）- 使用 v2 通道
• 实时更新 1.2.4 (兼容 1.2.3)
• 实时更新 2.0.1 (兼容 2.0.0)

策略：始终使用defaultChannel为主版本

推荐方法： 为每个主版本设置一个 defaultChannel 。这样你就可以始终将更新推送到特定用户组，而不依赖动态通道分配。

// Version 1.x releases
defaultChannel: 'v1'

// Version 2.x releases
defaultChannel: 'v2'

// Version 3.x releases (future)
defaultChannel: 'v3'

提示

此方法的好处：

• 始终有控制权 在用户接收更新的__CAPGO_KEEP_0__
• 不需要在应用中切换动态频道 在您的应用中需要code
• 不同应用版本之间的清晰分离 灵活性
• 推送任何特定版本组的更新 1. 为新版本创建频道

频道创建标题：1. 为新版本创建频道

# Create channel for version 2.x
npx @capgo/cli channel create v2

2. 为版本2.0.0更新Capacitor配置

在发布应用商店版本 2.0.0之前，更新您的Capacitor配置:

capacitor.config.ts

import { CapacitorConfig } from '@capacitor/cli';

const config: CapacitorConfig = {
  appId: 'com.example.app',
  appName: 'Example App',
  plugins: {
    CapacitorUpdater: {
      // ... other options
      defaultChannel: 'v2' // All 2.0.0 users will use v2 channel
    }
  }
};

export default config;

注意

对于版本 1.x： 如果您没有设置一个 defaultChannel 最初，版本 1.x 用户位于 production 频道。对于未来的重大版本，始终设置一个特定的频道，如 v3, v43. 管理独立的__CAPGO_KEEP_0__分支

Code

为应用程序版本之间保持兼容性而创建独立的git分支：

# Create and maintain a branch for version 1.x updates
git checkout -b v1-maintenance
git push origin v1-maintenance

# Your main branch continues with version 2.x development
git checkout main

重要： 永远不要将JavaScript包推送到期望native code/APIs但没有的旧应用程序。始终从适当的分支中构建更新：

• v1-maintenance branch: 1.x应用程序更新（生产频道）
• main branch: 2.x应用程序更新（v2频道）

4. 将包上传到相应的频道

# For 1.x updates: Build from v1-maintenance branch
git checkout v1-maintenance
# Make your 1.x compatible changes here
npx @capgo/cli bundle upload --channel production

# For 2.x updates: Build from main branch
git checkout main
# Make your 2.x changes here
npx @capgo/cli bundle upload --channel v2

5. 启用自我赋值

# Allow apps to self-assign to v2 channel
npx @capgo/cli channel set v2 --self-assign

6. 部署到 App Store

将版本 2.0.0 构建并部署到应用商店。所有下载此版本的用户（新用户或升级的现有用户）都会自动使用 v2 通道，因为它在应用程序包中配置了。

注意

无需任何 code 变更! 自从 defaultChannel: 'v2' 与应用商店版本捆绑，所有下载版本 2.0.0 的用户都会自动使用正确的渠道。

适应未来版本

当您发布 3.0.0 版本时，带有更多破坏性更改：

# Create channel for version 3.x
npx @capgo/cli channel create v3

// capacitor.config.ts for version 3.0.0
const config: CapacitorConfig = {
  // ...
  plugins: {
    CapacitorUpdater: {
      defaultChannel: 'v3' // Version 3.x users
    }
  }
};

现在您可以推送任何版本的更新：

• production 渠道 → 版本 1.x 用户
• v2 渠道 → 版本 2.x 用户
• v3 渠道 → 版本 3.x 用户

7. 清理（迁移后）

所有用户都迁移到 2.x 版本后（计 3-4 个月）：

1. 删除 defaultChannel 从您的 Capacitor 配置中
2. 删除 v2 频道：

npx @capgo/cli channel delete v2

3. 删除 v1-maintenance Branch：

git branch -d v1-maintenance
git push origin --delete v1-maintenance

提示

这种方法确保用户只接收与他们应用程序版本兼容的更新

始终在每个渠道中彻底测试更新之前部署

注意

Capgo 中的 v2 渠道即使有用户仍然覆盖了该渠道，也可以安全地删除。他们将自动从生产渠道接收更新。

维护 1.x 版本更新

要发送与 1.x 版本兼容的更新：

1. 切换到 v1-maintenance Branch：

git checkout v1-maintenance

2. Make your changes and commit:

# Make 1.x compatible changes
git add .
git commit -m "Fix for v1.x"
git push origin v1-maintenance

3. Build and upload to production channel:

npx @capgo/cli bundle upload --channel production

提示

保持v1-maintenance branch与bug修复保持同步，bug修复与版本1.x兼容，但从主分支中永远不要合并破坏性变更

继续从Breaking Changes

如果您正在使用 Breaking Changes 为计划通道路由和分阶段发布做准备,连接它 Channels Channels的实现细节 Channels Channels的实现细节 Channels Channels的实现细节 Beta Testing Solution 为Beta Testing Solution中的产品工作流程 Version Targeting Solution 为Version Targeting Solution中的产品工作流程