破坏性更改

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

示例场景

假设您有：

• 应用程序版本 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'

提示

此方法的好处：

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

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

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

2. Update Capacitor Config for Version 2.0.0

在发布应用商店版本 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, v4等等。

3. 管理独立的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应用程序的更新（生产频道）
• : 对2.x应用程序的更新（v2频道）4. 将包上传到相应的频道

Section titled “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 变更! 自此版本开始，所有下载2.0.0版本的用户都会自动使用正确的渠道。 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 1.x compatible changes
git add .
git commit -m "Fix for v1.x"
git push origin v1-maintenance

3. 构建并上传到生产频道:

npx @capgo/cli bundle upload --channel production

提示

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

继续从 Breaking Changes

如果您正在使用 重大变更 __CAPGO_KEEP_0__ 频道 频道 频道 频道 Beta 测试解决方案 Beta 测试解决方案中的产品工作流程 版本目标解决方案 版本目标解决方案中的产品工作流程 for the implementation detail in __CAPGO_KEEP_0__, and for the implementation detail in __CAPGO_KEEP_0__