AnalyseDeCircuit/oxideterm

OxideTerm リリース

リポジトリ所有の自動化を通じてOxideTermリリースを公開します。ユーザーの完了したGUI実行をリリースゲートとして扱い、デフォルトではCargoテストを実行しません。

必要なリリース入力

リリース変更を行う前に、以下の値を解決してください：

• ターゲットバージョン。
• ターゲットチャンネル：stable、beta、またはgpui-preview。
• ユーザーがGUIアプリケーションを実行し、公開を承認したことの明示的な確認。
• ユーザーが明示的にminimal、medium、またはdetailedを要求した場合のリリースノート詳細レベル。それ以外の場合はdetailedを使用します。

バージョンが曖昧でない場合にのみチャンネルを推測します。GUI承認がない場合は公開前に確認を求めてください。チェンジログの準備やドライランは承認を必要としません。

チャンネル契約

チャンネル	バージョン	タグ	チェンジログ	ベースノート
安定版	X.Y.Z	vX.Y.Z	.github/release-notes/stable-changelog.md	.github/release-notes/stable.md
ベータ版	X.Y.Z-beta.N	vX.Y.Z-beta.N	.github/release-notes/beta-changelog.md	.github/release-notes/beta.md
GPUIプレビュー	X.Y.Z-gpui-preview.N	gpui-vX.Y.Z-gpui-preview.N	.github/release-notes/gpui-preview-changelog.md	.github/release-notes/gpui-preview.md

他のタグプレフィックスを発明しないでください。ネイティブパッケージワークフローは、release_tagディスパッチ入力から既存のタグを受け取り、そのタグからリリースノートを選択します。

ワークフロー

1. リポジトリ状態の検査

OxideTermリポジトリのルートから作業します。AGENTS.mdを読み、次に検査します：

git status --short --branch
git remote -v
git log -10 --oneline --decorate

タグが利用可能と判断する前に、公開リモートとタグをフェッチします：

git fetch origin --tags

ブランチが上流より遅れていないか、分岐していないことを確認し、ローカルおよびリモートでターゲットタグを検査します：

git rev-list --left-right --count HEAD...@{upstream}
git tag --list <tag>
git ls-remote --origin tags refs/tags/<tag> refs/tags/<tag>^{}

無関係なユーザー変更を保持します。意図したリリース範囲を安全に分離できない場合、またはブランチが分岐している場合は停止します。通常のリリースでは、ターゲットタグが存在する場合は停止します。明示的なキャンセル済みリリース回復手順（後述）によってのみ、既存のタグを移動します。

2. チェンジログ範囲の確立

チェンジログを書く前に、バンドルされたヘルパーを実行します：

python3 .agents/skills/oxideterm-release/scripts/release_context.py \
  --repo . --channel <channel> --version <version>

ベースラインとして、同じチャンネルから到達可能な前回のタグを優先します：

• 安定版は前回の安定版タグと比較します。
• ベータ版は前回のベータ版タグと比較します。
• GPUIプレビューは前回のGPUIプレビュータグと比較します。

チャンネルの最初のリリースでは、3つのチャンネルのいずれかから最も新しい到達可能なリリースタグをブートストラップベースラインとして使用します。リポジトリに以前の到達可能なリリースタグがない場合にのみ、ルートコミットを使用します。これにより、最初のベータ版またはプレビュー版のチェンジログが、実際の先行リリース以降の作業に限定され、リポジトリ全体を要約することを防ぎます。

ヘルパーは正確な範囲、コミット、差分サマリーを出力します。また、意図した未コミットの変更を含む実際の変更も検査します：

git diff <previous-tag>..HEAD
git diff
git diff --cached

コミット件名のみからリリースノートを導出しないでください。意味のある実装とユーザー向けの違いを読んでください。機械的なバージョンバンプ、チェンジログの編集、フォーマットのみの変更、リリースに影響を与えない内部詳細は除外します。

プルリクエストとコントリビューターの解決

すべてのリリースチャンネルについて、ノートを作成する前に、正確なリリース範囲内の変更を元のプルリクエストにマッピングします。ヘルパーのコミットリストはマージコミットを除外します。マージ履歴とGitHubのコミットからPRへの関連付けも検査して、マージ、スカッシュマージ、リベースマージが適切に帰属されるようにします：

git log --format='%H %s' <previous-tag>..<target-ref>
gh api --paginate repos/<owner>/<repo>/commits/<commit-sha>/pulls \
  --jq '.[] | {number, title, url: .html_url, author: .user.login, merged_at, merge_commit_sha}'
gh pr view <number> --repo <owner>/<repo> \
  --json number,title,url,author,mergedAt,mergeCommit,commits

含まれる各PRの番号、URL、著者ログイン、実際の貢献の作業マッピングを維持します。複数のコミットに対して返されたPRを重複排除します。ターゲット履歴と差分に対して包含を確認します。マージ日だけではリリース範囲を確立できません。チェリーピックされた変更の元のPRの出所を確認します。完全にリバートされた変更は、出荷された機能として提示してはいけません。

PR著者（マージした人やボットではなく）を使用します。コントリビューターへの感謝では、確認されたプロジェクトメンテナーとボットアカウントを除外します。人間のコントリビューターがGitHubでCOLLABORATORまたはMEMBERとラベル付けされているという理由だけでメンテナーと見なさないでください。メンテナーがフォローアップ修正を行った場合でも、外部PR作業のクレジットを保持します。参照されたイシュー番号は、PRやその著者の証拠ではありません。GitHubルックアップが失敗した場合は、未解決の帰属を作業メモに保持し、リリースノートを確定する前に解決します。ルックアップの失敗を「貢献なし」と解釈しないでください。

3. チャンネルチェンジログの作成

選択したチェンジログに、## <version> を最新のエントリとして挿入します。見出しはバージョンと正確に一致する必要があります。.github/scripts/compose_release_notes.py がこの見出しを使用してエントリを見つけるためです。見出しは抽出の境界であり、必ずしも公開されるリリース本文の一部ではありません。

すべてのバージョンエントリを、この順序で2つの完全な言語ブロックとして記述します（最初に中国語、次に英語）。コンポーザーは、すべてのチャンネルの二言語リリースノートの最上部に言語ジャンプリンクを追加します：

## <version>

### 中文

<Chinese summary and sections>

### English

<English summary and sections>

両方のブロックを構造的に揃えます。同じ結果、制限、検証ステータス、アップグレード要件を同じ順序で記述する必要があります。自然なリリースノート言語に翻訳し、単語ごとではなく、製品名、コマンド、ファイル名、プロトコル名は精度が低下する場合は変更しないでください。英語と中国語を同じ箇条書きにマージしないでください。英語では簡潔なユーザー向け過去形を使用し、中国語では簡潔な完了アクション表現を使用します。各言語の冒頭の要約段落は1物理行に保ち、GitHub Releaseエディタで人為的な改行が表示されないようにします。関連するコミットを1つの成果にまとめ、コミットタイトルのダンプ、実装の詳細、未検証のパフォーマンス主張、検証されていない主張を避けます。両方のブロックの主要な安定版リリースセクション見出しに、1つの控えめで意味的に関連する絵文字を使用します。すべての箇条書きを装飾したり、1つのセクション内で複数の絵文字スタイルを混在させたりしないでください。

フォークリリースの場合、各言語ブロックは、公式OxideTerm上流から継承された変更とフォークによって実装された変更を明確に分離する必要があります。Upstream changes / 上游更新、Fork-specific changes / Fork 自有更新に相当する明示的なローカライズ見出しを使用します。選択した詳細レベルがそれを正当化する場合、サブシステム見出しをそれらの下にネストできます。マージまたはチェリーピックされた公式作業は、コミット作成者に関係なく上流として分類し、公開フォークに固有の動作をフォーク固有として分類します。フォークが上流機能を変更する場合、継承された機能を上流で説明し、フォークの実質的な差分をフォーク固有の変更で説明します。いずれかのカテゴリでリリース範囲に変更がない場合は、カテゴリを省略するのではなく、明示的にその旨を記述します。複合サマリーや箇条書きで、フォークが上流作業を作成したと暗示しないでください。

PR参照とコントリビューターへの感謝

NyaTerm v1.2.12 の属性パターンに従います。PR参照はそれが導入した変更の横に配置し、専用のコントリビューターセクションも設けます。実際のエントリはOxideTermのリリース範囲から導出します。

• メンテナー作成のPRを含む、PRを通じて導入されたすべてのリリースノート項目に、リンクされたPR番号を追加します。中国語では（PR [#<number>](<pr-url>)）、英語では(PR [#<number>](<pr-url>))を使用します。参照は、関連する箇条書きまたは機能段落の最後に配置し、コントリビューターリストや完全なチェンジログリンクのみに配置しないでください。イシューリンクはPRリンクとは別にします。直接コミットには架空のPR番号を付けません。
• 複数のPRがグループ化された項目に貢献した場合は、その項目にすべての関連PR番号を1回含めます。各PRがサポートする成果のみを属性として割り当てます。グループ化によって誤った著者にクレジットが与えられる場合は、メンテナーの独立したフォローアップ変更を分離します。別のリポジトリからのPRの場合は、リンクラベルをowner/repo#numberで修飾します。
• リリースに外部PRコントリビューションが含まれる場合は常に、中国語ブロック内に#### 👥 贡献者を追加し、英語ブロック内に#### 👥 Contributorsを追加します。変更セクションの後、アップグレードノート（存在する場合）の前に配置します。このリリースに含まれるすべての外部PR著者に感謝します。これには、リピーターのコントリビューターや、ドキュメント、翻訳、ビルド、パッケージングのコントリビューターで、スタンドアロンの機能箇条書きを必要としない作業を行った場合も含まれます。
• 各著者を言語ブロックごとに1回リストし、検証済みのGitHub @login、その貢献の簡単な説明、リンクされたPR番号を使用します。著者とPR参照を両方の言語で一致させます。一般的な感謝やGitHubの自動アバターストリップはこれらのエントリを置き換えません。初めてのコントリビューターを特定する場合は、以前のリポジトリへの貢献を検証します。New Contributorsリストは完全な感謝セクションを補足します。
• すべての詳細レベルとすべてのチャンネルで帰属を適用します。検証された範囲に外部PRコントリビューションが含まれていない場合は、空の見出しを追加するのではなく、コントリビューターセクションを省略します。リリース範囲外のPRは、このバージョンへの新しい貢献としてクレジットされません。

コントリビューターエントリの例（プレースホルダーを検証済みのリリースデータに置き換えます）：

#### 👥 贡献者

感谢以下外部贡献者参与本次更新：

- @<login>：<具体贡献>（PR [#<number>](<pr-url>)）。

#### 👥 Contributors

Thank you to the external contributors to this release:

- @<login>: <specific contribution> (PR [#<number>](<pr-url>)).

2つの例セクションをそれぞれの言語ブロックに配置し、3つ目の二言語セクションとして一緒に配置しないでください。

リリースノートの詳細レベル

英語と中国語のブロックで同じレベルを使用します。レベルはカバレッジとグループ化を制御しますが、必須の単語数ではありません。短いレベルを満たすために、破壊的変更、セキュリティ境界、アップグレード要件、既知の制限、または重要な互換性の問題を省略しないでください。

レベル	必須密度
minimal	ユーザーが明示的に要求した場合のみ使用します。1つの短いサマリーと、約2～5の高度に統合された成果箇条書きを書き、スキャンに実質的に役立つ場合にのみ最大1つまたは2つの見出しを使用します。リリースの主要なユーザー向け変更と必要な警告のみをカバーします。
medium	ユーザーが明示的に要求した場合のみ使用します。1つのサマリー、少数の有用なセクション、主要な機能、修正、セキュリティまたは互換性の結果をカバーするグループ化された箇条書きを書きます。関連するサポートワークフローを統合し、個別に列挙しないでください。
detailed	ユーザーが明示的に別のレベルを選択しない限り、デフォルトです。意味のあるサブシステムまたはワークフローごとにノートを整理し、各々の明確なユーザー向け機能、動作変更、互換性修正、サポートされている制限、検証されたパフォーマンスまたは検証結果に、差分を読まなくても理解できる十分なスペースを与えます。変更の理解や使用方法に実質的に影響を与える場合にサポートワークフローを含めますが、リリースに実際の変更が少ない場合はフィラーを追加しないでください。

レベルをカバレッジとグループ化のガイダンスとして扱い、固定テンプレートとしては扱いません。まず完全な事実上の差分を決定し、次にそれを選択されたレベルに統合します。ユーザーが「リリースノートを書いて」または「リリースを準備して」とだけ言った場合は、detailedを使用します。

チャンネル固有の強調を適用します：

• 安定版： 前回の安定版タグ以降の完全な差分を要約します。各言語ブロックで、1つの短いリリースサマリーから始め、#### ✨ 亮点 / #### ✨ 重点更新、#### 🛠️ 修复 / #### 🛠️ 修复、#### 🔒 安全 / #### 🔒 安全、または#### 🧰 发布维护 / #### 🧰 发布维护 などの有用なセクションのみを使用します。ユーザー向けの動作と互換性を強調します。構成されたGitHub Release本文は、[中文](#中文) | [English](#english) ナビゲーションで始まり、その後に完全な### 中文ブロック、そして対応する### Englishブロックが続き、# OxideTerm 2.0 などの製品メジャー見出しや## 2.0.7 などのバージョン見出しの繰り返しは省略し、両方の言語ブロックの後に## 📥 お使いのシステムにダウンロード、インストールのヒント、リンクを配置します。
• ベータ版： 前回のベータ版タグ以降の差分を、完全な英語と中国語のブロックで要約します。安定版に近づいているもの、変更されたもの、検証が必要なワークフローを明記します。既知の制限は、差分またはイシューコンテキストによってサポートされている場合にのみ言及し、両方の言語に含めます。
• GPUIプレビュー： 前回のGPUIプレビュータグ以降の差分を、完全な英語と中国語のブロックで要約します。新しくテスト可能になったネイティブUI/ランタイム作業、パリティ、未完成部分、具体的なテストターゲットに焦点を当てます。選択された詳細レベルを適用しながら、プレビューノートを安定版リリースのマーケティングに変えるのではなく、テスト指向の記述を維持します。

そのチャンネルに以前のタグがない場合は、ブートストラップベースラインとして使用された先行リリースタグを明記します。

4. リポジトリバージョンスクリプトの実行

常にリポジトリスクリプトを使用します。ワークスペースバージョンやロックファイルを手動で編集しないでください：

python3 scripts/release/bump_version.py <version>

これにより、SemVerの検証、[workspace.package]の更新、Cargo.lockのオフラインリフレッシュが行われます。READMEバッジは最新のGitHubリリースを自動的に表示するため、バージョン編集は不要です。

5. 軽量リリース検証の実行

cargo testを実行しないでください。

…[翻訳のため省略]