破壊的変更

このドキュメントでは、バージョン管理されたチャンネルを使用して、アプリの破壊的変更（breaking changes）をどのように扱うかを説明します。この手法により、ユーザーに互換性のあるアップデートを確実に届けつつ、アプリの異なるバージョンを並行して維持できます。

シナリオ例

例えば、以下のような状況を想定します：

• アプリバージョン 1.2.3（旧バージョン）- production チャンネルを使用
• アプリバージョン 2.0.0（破壊的変更を含む新バージョン）- v2 チャンネルを使用
• Live update 1.2.4（1.2.3 と互換性あり）
• Live update 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. 新しいバージョン用の Channel を作成する

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

2. バージョン 2.0.0 用の Capacitor 設定を更新

App Store向けにバージョン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 channel に割り当てられています。今後のメジャーバージョンでは、常に以下のような特定の channel を設定してください： 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

重要: ネイティブの code/API を期待しているが、それを持たない古いアプリに JavaScript bundle をプッシュしないでください。アップデートは必ず適切なブランチからビルドしてください:

• v1-maintenance ブランチ: 1.x アプリのアップデート用 (production チャネル)
• main ブランチ: 2.x アプリのアップデート用 (v2 チャネル)

4. 各チャネルへの Bundle アップロード

# 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をビルドしてApp Storeにデプロイします。このバージョンをダウンロードしたすべてのユーザー（新規ユーザーおよびアップグレードする既存ユーザーの両方）は、アプリのバンドル内で設定されているため、自動的にv2チャンネルを使用します。

注意

code の変更は不要です！ 追加バージョン defaultChannel: 'v2' App Store版にバンドルされるため、バージョン2.0.0をダウンロードしたすべてのユーザーは、自動的に正しいチャンネルを使用します。

将来のバージョンへのスケーリング

さらに破壊的変更を含むバージョン3.0.0をリリースする場合：

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

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

任意のバージョンに対してアップデートをプッシュできるようになります：

• production channel → バージョン1.xのユーザー
• v2 channel → バージョン2.xのユーザー
• v3 channel → バージョン3.xのユーザー

7. クリーンアップ（移行後）

すべてのユーザーがバージョン2.xへ移行完了した後（目安：3〜4ヶ月後）：

1. 削除 defaultChannel Capacitor の設定から
2. v2 チャンネルを削除します：

npx @capgo/cli channel delete v2

3. v1-maintenance ブランチを削除します：

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

ヒント

この手法により、ユーザーにはアプリのバージョンに互換性のあるアップデートのみが配信されます

デプロイ前に、必ず各チャンネルでアップデートを十分にテストしてください

注意

Capgo の v2 チャンネルは、一部のユーザーにチャンネルの上書き設定が残っていても安全に削除できます。それらのユーザーには、自動的に production チャンネルからアップデートが配信されます。

バージョン 1.x のアップデートを維持

Version 1.x と互換性のあるアップデートを配信するには：

1. v1-maintenance ブランチに切り替えます：

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ブランチは、1.xと互換性のあるバグ修正で最新の状態に保ち、mainからの破壊的変更は絶対にマージしないでください。

Breaking Changes から続ける

以下を使用している場合： 破壊的変更 チャネルのルーティングと段階的ロールアウトを計画するには、それを次と接続します チャネル Channelsの実装の詳細については、 チャネル Channelsの実装の詳細については、 チャネル Channelsの実装の詳細については、 ベータテスト・ソリューション Beta Testing Solutionのプロダクトワークフロー向けに、また バージョン指定ソリューション Version Targeting Solutionのプロダクトワークフロー向けに。