拡張機能のリリース
ユーザーに拡張機能をリリースする主な方法は2つあります：
Gitリポジトリでのリリースは、最もシンプルで柔軟性のあるアプローチですが、GitHub Releasesは初期インストール時により効率的です。これは、各ファイルを個別にダウンロードするgit cloneを必要とする代わりに、単一のアーカイブとして配布されるためです。また、プラットフォーム固有のバイナリファイルを配布する必要がある場合、GitHub Releasesにはプラットフォーム固有のアーカイブを含めることもできます。
Gitリポジトリを通したリリース
これは最も柔軟でシンプルなオプションです。必要なのは、公開可能なGitリポジトリ（例：パブリックなGitHubリポジトリ）を作成することだけです。そうすれば、ユーザーは qwen extensions install <your-repo-uri> を使用して拡張機能をインストールできます。GitHubリポジトリの場合は、簡略化された qwen extensions install <org>/<repo> 形式も利用可能です。また、任意で --ref=<some-ref> 引数を使用して特定のref（ブランチ／タグ／コミット）に依存関係を指定でき、デフォルトではデフォルトブランチが使用されます。
ユーザーが依存しているrefにコミットがプッシュされるたびに、拡張機能の更新が促されます。この方法により、簡単にロールバックも可能になります。HEADコミットは常に最新バージョンとして扱われ、qwen-extension.json ファイル内の実際のバージョンとは無関係です。
Git リポジトリを使用したリリースチャネルの管理
ユーザーは、ブランチやタグなど、Git リポジトリ内の任意の ref に依存できるため、複数のリリースチャネルを管理できます。
例えば、stable ブランチを維持し、ユーザーが qwen extensions install <your-repo-uri> --ref=stable のようにインストールできるようにできます。あるいは、デフォルトブランチを安定版リリース用として扱い、別のブランチ（例：dev）で開発を行うことで、これをデフォルトにすることができます。好きなだけ多くのブランチやタグを維持でき、あなたとあなたのユーザーに最大限の柔軟性を提供します。
これらの ref 引数は、タグ、ブランチ、あるいは特定のコミットでもよく、ユーザーが拡張機能の特定バージョンに依存することを可能にします。タグやブランチの管理方法は完全にあなた次第です。
git リポジトリを使用したリリースフローの例
git フローを使ってリリースを管理する方法は多数ありますが、デフォルトブランチを「安定版 (stable)」リリースブランチとして扱うことを推奨します。これは、qwen extensions install <your-repo-uri> のデフォルト動作が、安定版リリースブランチを対象とすることを意味します。
例えば、stable、preview、dev の3つの標準的なリリースチャネルを維持したいとしましょう。この場合、すべての通常の開発作業は dev ブランチで行います。プレビュー版リリースの準備ができたら、そのブランチを preview ブランチにマージします。そして、プレビュー版を安定版に昇格させる準備ができたら、preview を安定版ブランチ（デフォルトブランチかもしれないし、別のブランチかもしれない）にマージします。
また、git cherry-pick を使ってあるブランチから別のブランチへ変更をピックアップすることもできますが、これにより各ブランチの履歴が若干分岐してしまうことに注意してください。ただし、各リリース時にブランチに強制プッシュして履歴をクリーンな状態に戻すことで回避できます（ただし、リポジトリ設定によってはデフォルトブランチでは不可能な場合があります）。チェリーピックを行う予定がある場合は、デフォルトブランチを安定版ブランチにしないようにすると、デフォルトブランチへの強制プッシュを避けられて良いでしょう（一般的に強制プッシュは避けるべきです）。
GitHub リリースを通した配布
Qwen Code 拡張機能は、GitHub Releases を通じて配布できます。これにより、リポジトリをクローンする必要がなくなるため、ユーザーにとって初期インストールの体験がより速く、より信頼性が高くなります。
各リリースには少なくとも1つのアーカイブファイルが含まれており、そのファイルにはタグに関連付けられた時点でのリポジトリの全内容が格納されています。拡張機能にビルド手順が必要であったり、プラットフォーム固有のバイナリが添付されている場合は、リリースに事前ビルド済みアーカイブを含めることも可能です。
アップデート確認時には、qwen code は単純に GitHub 上の最新リリースを検索します（リリース作成時にそのようにマークしておく必要があります）。ただし、ユーザーが --ref=<some-release-tag> を指定して特定のリリースをインストールした場合は除きます。現時点では、プレリリースやセマンティックバージョニング（semver）へのオプトインはサポートしていません。
カスタムの事前ビルドアーカイブ
カスタムアーカイブは、GitHubリリースに直接アセットとして添付され、完全に自己完結している必要があります。これは、拡張機能全体を含める必要があることを意味し、アーカイブ構造を参照してください。
拡張機能がプラットフォームに依存しない場合は、単一の汎用アセットを提供できます。この場合、リリースに添付されるアセットは1つだけであるべきです。
カスタムアーカイブは、より大きなリポジトリ内で拡張機能を開発したい場合にも使用できます。その場合、リポジトリ自体とは異なるレイアウトのアーカイブをビルドできます（例えば、拡張機能を含むサブディレクトリのアーカイブのみである可能性があります）。
プラットフォーム固有のアーカイブ
Qwen Code が各プラットフォームに適したリリースアセットを自動的に見つけられるようにするため、以下の命名規則に従う必要があります。CLI は次の順序でアセットを検索します：
- プラットフォームおよびアーキテクチャ固有:
{platform}.{arch}.{name}.{extension} - プラットフォーム固有:
{platform}.{name}.{extension} - 汎用: アセットが1つだけ提供されている場合、それは汎用のフォールバックとして使用されます。
{name}: 拡張機能の名前。{platform}: オペレーティングシステム。サポートされる値：darwin(macOS)linuxwin32(Windows)
{arch}: アーキテクチャ。サポートされる値：x64arm64
{extension}: アーカイブのファイル拡張子（例：.tar.gzや.zip）。
例:
darwin.arm64.my-tool.tar.gz(Apple Silicon Mac 専用)darwin.my-tool.tar.gz(すべての Mac 向け)linux.x64.my-tool.tar.gzwin32.my-tool.zip
アーカイブ構造
アーカイブは完全に自己完結型の拡張機能であり、すべての標準要件を満たしている必要があります。具体的には、qwen-extension.json ファイルがアーカイブのルートに配置されている必要があります。
その他のレイアウトは、典型的な拡張機能と全く同じようにする必要があります。extensions.md を参照してください。
GitHub Actions ワークフローの例
以下は、複数のプラットフォーム向けに Qwen Code 拡張機能をビルドおよびリリースする GitHub Actions ワークフローの例です：
name: Release Extension
on:
push:
tags:
- 'v*'
jobs:
release:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: '20'
- name: Install dependencies
run: npm ci
- name: Build extension
run: npm run build
- name: Create release assets
run: |
npm run package -- --platform=darwin --arch=arm64
npm run package -- --platform=linux --arch=x64
npm run package -- --platform=win32 --arch=x64
- name: Create GitHub Release
uses: softprops/action-gh-release@v1
with:
files: |
release/darwin.arm64.my-tool.tar.gz
release/linux.arm64.my-tool.tar.gz
release/win32.arm64.my-tool.zip