リリースライフサイクル標準 (v1.3)¶

Cloto ファミリーのプロジェクト向けの、3 ティアのリリースライフサイクルおよびサポートの標準です。本ドキュメントは仕様であり、これを採用するリポジトリは、ここにあるテンプレートから導出した自前の運用ポリシーとして SUPPORT.md (ティア表 + ステータス) と SECURITY.md を公開します。

翻訳について: 本標準の規範的な正本は英語版です。記述が食い違う場合は英語版が優先されます (右上の言語切替から参照できます)。

この文書のステータス¶

パイロット運用中。 本標準は、互いに補完的な役割を持つ 2 つのリポジトリでパイロット運用されています: cpersona (ポリシー運用と品質ベースラインのリファレンス実装) と ClotoCore (構造的強制のリファレンス実装 — ティアの規則がレジストリ上の慣習として適用されるのではなく、update-channel / release-manifest のパイプラインに焼き込まれています。同リポジトリの docs/RELEASE_PIPELINE_DESIGN.md を参照)。以下のすべての規則は、ファミリー全体への採用に先立ち、実際のリリースに対して実行され検証されます。Cloto ファミリーのパブリックリポジトリは、パイロットが評価基準 (§6) を満たした時点で段階的に本標準を採用します。プライベートリポジトリは対象外です。

正本の所在: パイロット運用中は本リポジトリです。本標準がファミリー全体で採用された場合、正本の所在はファミリーレベルのリポジトリへ移る可能性があり、その際は本ドキュメントがそこへのポインタになります。

1. ティア¶

各リリースライン (例: 2.4.x) は、常にちょうど 1 つのティアに属します。ティアは個々のバージョンではなくラインに紐づきます。

ティア	意味	修正ポリシー
Stable	本番環境での soak を経てメンテナが認定したライン。全ユーザーに推奨され、既定の配布チャネル (例: マーケットプレイスの pin) はこのラインを配信します。	クリティカルなバグ修正、データ損失の修正、セキュリティ修正のみ。メンテナの裁量でバックポートされます。
Current	最新のリリースライン。リポジトリのフルのリリースゲートは通過済みですが、本番環境での認定はまだ受けていません。	すべてのバグ修正はまずここに入ります。開発が行われるのはこのラインです。
Experimental	次期ラインの alpha / beta (必要なら rc) の pre-release。opt-in 専用で、いかなる保証もありません。	修正は次の pre-release で出荷されます。

用語についての注記: Current は Node.js のリリースフェーズの語彙 (本番ティアとは区別される、サポート対象の最新ライン) に倣っています — BSD の開発 HEAD である -CURRENT ではありません。その役割はここでは Experimental が担います。 Experimental は React のリリースチャネルの用法 (opt-in、保証なし) に一致します。Stable の修正ゲートは Node.js の Maintenance LTS ("critical bug fixes and security updates") および Linux カーネルの stable ルールに一致します。

2. ライフサイクル¶

X.Y.0aN → X.Y.0bN (→ X.Y.0rcN if needed) → X.Y.0     [Experimental]
                                              │  release gate passed
                                              ▼
                                           Current
                                              │  production soak + maintainer certification
                                              ▼
                                           Stable ──── the previously Stable line enters Grace
                                              │  a successor line is certified Stable
                                              ▼
                                     Grace (30 days) → EOL

2.1 Pre-release (Experimental)¶

Python プロジェクトは PEP 440 の正規バージョン文字列 (2.5.0a1、 2.5.0b1、2.5.0rc1) を使い、git タグは 1:1 で対応します (v2.5.0a1)。 Python 以外のプロジェクトは、同じステージ意味論のまま、各エコシステムの pre-release 表記 (例: semver の -alpha.1) を使います。
インストーラレベルでの opt-in 性質を成立させなければなりません (MUST): 素のインストールが pre-release に解決されることは決してありません (pip は --pre なしでは pre-release を除外します。他のエコシステムも pre-release フラグ / dist-tag で同じ効果を得ます)。
rc ステージは任意です。alpha → beta → final が既定の ladder です。
この ladder はリスクによって発火するものであり、一律ではありません。 ロールバック安全でない変更 — データベーススキーマまたはデータのマイグレーション、公開ツール / API 契約の破壊、既定の挙動の変更 — を含むリリースは、 pre-release ladder を通らなければなりません (MUST)。追加的で挙動を保存するリリースは、ladder を省略して direct-to-final でリリースしてもよい (MAY) (§2.1 のインストーラ opt-in 性質および §4 の配布マッピングと整合します — direct な final は単に Current の最新リリースになるだけです)。迷った場合は ladder を使ってください。

2.2 リリースゲート (Current への入場)¶

各リポジトリは自身のゲートを定義します。ゲートには最低限、フルのテストスイートと lint を含めなければなりません (MUST)。cpersona でのゲートは、pytest スイート (構造ゲートを含む)、ruff、issue レジストリの検証 (verify-issues.sh)、および相当量のバッチに対する包括的なマルチエージェント監査です。

2.3 認定 (Stable への昇格)¶

メンテナによる明示的かつイベントベースの判断です — 固定の時計はありません。目安: 新規のクリティカルまたは高深刻度の欠陥が出ないまま、数週間の本番 soak (実運用による慣らし) を経ること。認定日はリポジトリの SUPPORT.md のステータス表に記録され、同時に、置き換えられたラインの grace ウィンドウを開始させます。採用する各リポジトリは、自身の soak 環境を明示します (cpersona の場合: 本番の ClotoCore デプロイ)。

2.4 Grace ウィンドウ¶

後継ラインが Stable として認定されると、置き換えられたラインは認定日から 30 日間その Stable の修正ポリシーを維持し、その後 EOL に到達します。

時計は認定イベントを起点とします。ウィンドウ内のパッチリリースはこれをリセットしません。
ウィンドウ内に受理された問題の修正は、ウィンドウが閉じた後に出荷されることがあります。
移行がデータベーススキーマまたはデータのマイグレーションを必要とする場合 (cpersona のライン移行は DB スキーマを保存しますが、MCP ツール契約は無条件には保存されません — 2.5.2 は §2.1 の ladder の下でこれを破壊しました)、メンテナは後継を認定する前にウィンドウを延長すべきです (SHOULD)。

2.5 EOL¶

以後の修正はありません。EOL 後のセキュリティ修正はメンテナの単独裁量であり、当てにしてはなりません。

2.6 ライン内でのフィーチャーリリース¶

§2 のライフサイクル図はラインの誕生 (X.Y.0) を示すものであって、そのラインの開発の終わりを示すものではありません。Current にあるラインは、バグ修正リリースに加えてフィーチャーリリース (X.Y.1、X.Y.2、…) を受け入れてもよい (MAY):

ライン内の各リリースは、§2.1 のリスクトリガーに従って自身の経路を選びます: 追加的なフィーチャーリリースは direct-to-final で進んでよく、ロールバック安全でない変更はライン内リリースではなく次のライン (X.(Y+1).0) に属します。
認定 (§2.3) は、そのラインを最新リリース時点で評価します。したがって soak 期間中に出荷されたフィーチャーリリースは、事実上 soak の評価をやり直させます: メンテナはそのリリースを含めてラインを認定するか、まったく認定しないかのいずれかです。認定審査が進行中のラインにフィーチャーを投入することは、意図的なトレードオフであって抜け道ではありません。
Stable のラインはフィーチャーリリースを受け入れません — その修正ポリシー (§1) が既に、クリティカル・データ損失・セキュリティの修正に限定しています。フィーチャーは常に Current (あるいは次の Experimental) のラインを対象とします。

2.7 初期状態 (認定済みの Stable ラインが無い)¶

リポジトリの最初の認定イベント以前は、Stable のラインは存在しません。その状態では:

既定の配布チャネルは Current のラインを配信しなければなりません (MUST) (すなわち stable チャネルは最初の認定まで current のエイリアスになります)。
利用者に向いた面では、まだ Stable として認定されたラインが無いことを述べるべきです (SHOULD) (例: SUPPORT.md のステータス表に "Stable line not yet certified" の注記を置き、該当する場合は更新 UI にも置く)。
インストーラの opt-in 性質 (§2.1) は引き続き成立します: エイリアスされた既定チャネルが pre-release に解決されることは決してありません。
最初の認定でエイリアスは実際の pin に置き換わり、以後は §2.3–§2.5 がそのまま適用されます。

2.8 監査所見の識別子¶

リリースゲートの監査 (pre-release ladder における大規模レビュー、§2.1) は所見レポートを生み出します。採用リポジトリはさらに機械検査される issue レジストリ (cpersona では qa/issue-registry.json) を保持し、その id (bug-NNN) が欠陥の正準かつ恒久的な識別子です。2 つの id 空間が互いを汚染しないよう、2 つの規則を置きます:

監査レポートは深刻度の頭文字による所見 id を使う — C-NN (CRITICAL)、 H-NN (HIGH)、M-NN (MEDIUM)、L-NN (LOW)。ゼロ埋めし、1 回の監査の中で一意とします。裸の C プレフィックスは CRITICAL のために予約されており、それ以外の用途 (例: 「cluster」) に使ってはなりません (MUST NOT)。ワークフロー内部の作業 id (クラスタ番号、finder id) は監査の実行中に存在してよいものの、レポートの公開所見 id ではありません。
ツリーに入る id は正準 id のみ。 コードコメントと修正マーカー、テスト名、レジストリのパターンは、欠陥をもっぱらレジストリ id (bug-NNN) で参照します。正準 id は修正の実装が始まる前に採番されるため、修正ブリーフ・回帰テスト・レジストリのエントリは生まれた時点で正準です。監査 id は PR 本文や監査レポートの中で相互参照として正準 id に併記してよい (bug-114 (H-03)) ものの、コード中に単独で現れることは決してありません。

3. 必要な成果物 (採用リポジトリごと)¶

SUPPORT.md — 運用ポリシー: ティア表、ライフサイクルの要約、およびリポジトリのステータス表 (ライン / ティア / 認定・EOL の日付)。
SECURITY.md — SUPPORT.md を参照するサポート対象バージョンの表と、非公開の脆弱性報告チャネル。
その両方を指し示す短い README のセクション。

cpersona の SUPPORT.md / SECURITY.md がリファレンステンプレートです。

4. 配布マッピング¶

マーケットプレイス / ハブ: 既定の pin は Stable のラインを配信します。 pin が切り替わるのは認定時であって、リリース時ではありません。
PyPI / レジストリ: latest は自然に Current の最新の final リリースへ解決されます。Experimental は pre-release フラグの向こう側に留まります。
GitHub Releases: pre-release には "Pre-release" フラグが付き、"Latest" バッジは Current を追跡します。
更新マニフェスト / フィード (自前のアップデータを配布するリポジトリ): フィードはティアごとに 1 つのチャネルを露出し、名前はティア名をそのまま使います。既定チャネルは stable で、その pin は認定時 (§2.3) に切り替わります。これにより §2.1 と上のマーケットプレイスの規則が、慣習ではなく構造として効くようになります。リファレンス実装: ClotoCore のリリースパイプライン。

5. 採用チェックリスト (新規リポジトリ向け)¶

[ ] テンプレートから SUPPORT.md / SECURITY.md をコピーし、ステータス表にそのリポジトリの現行ラインを記入する。
[ ] リポジトリのリリースゲート (§2.2) と soak 環境 (§2.3) を定義する。
[ ] pre-release に対するインストーラの opt-in 性質を検証する (§2.1)。
[ ] 既定の配布チャネルを Stable のラインに向ける (§4)。
[ ] README のポインタセクションを追加する。
[ ] 本ドキュメントの §7 レジストリに採用を記録する。

6. パイロットの評価基準¶

パイロットは、以下が満たされた時点で成功とみなされ、ファミリー全体への採用が解禁されます:

cpersona でライフサイクルが 1 周完了すること (2.5.x: Experimental → Current → Stable 認定、2.4.x: Grace → EOL)。しかもポリシーが、自身では表現できないその場しのぎの判断を強いることなく完了すること (そうした欠落はすべて標準側の欠陥です: 標準を修正し、そのバージョンを上げます)。
機械的なフックが仕様どおりに振る舞うこと: pip の pre-release 除外、認定時のハブ pin の切り替え、ステータス表の記帳。
ティアの語彙や grace ウィンドウの意味論に起因する、利用者側の混乱インシデントが発生しないこと。

失敗はパイロットを中止させません。クリーンな 1 周が通るまで標準 (v1.x) を反復します。

7. 採用レジストリ¶

リポジトリ	標準バージョン	採用日	備考
cpersona	v1.3	2026-07-09	パイロット / リファレンス実装 (ポリシー運用)。最新の標準バージョンに追随します (正本の所在)。
ClotoCore	v1.3	2026-07-12	2 つ目のパイロット / リファレンス実装 (update-channel + 署名済みマニフェストのパイプラインによる構造的強制、`docs/RELEASE_PIPELINE_DESIGN.md`)。

8. 変更履歴¶

v1.3 (2026-07-23) — 監査所見の識別子の規約 (§2.8): 深刻度の頭文字によるレポート id、ツリー内では正準レジストリ id のみ、実装より前の正準採番。 cpersona 2.5.2a2 の是正作業で表面化しました。そこではクラスタ番号方式の C## が深刻度頭文字の系譜と衝突し (クラスタ id が CRITICAL と誤読された)、監査の作業 id が疑似マーカーとしてコードコメント・テスト名・レジストリのパターンへ漏れ出したため、正準化のパスが必要になりました。
v1.2 (2026-07-16) — リスク駆動の pre-release ladder の基準 (§2.1) とライン内フィーチャーリリースの規則 (§2.6)。2.5.1 の計画議論 (サーバー提供の operating context、X.Y.0 がまだ Experimental にあるラインを対象とした追加的フィーチャー) で表面化しました — いずれも §6 の「標準側の欠陥」であり、標準自身の手順に従って修正しています。旧 §2.6 は §2.7 に採番し直しました。
v1.1 (2026-07-12) — 認定済みの Stable ラインを持たないリポジトリ向けの初期状態の規則 (現 §2.7。ClotoCore の採用で表面化した §6 の「標準側の欠陥」であり、標準自身の手順に従って修正)。配布マッピング (§4) への更新マニフェスト / フィードの行。2 つ目のパイロット (構造的強制のリファレンス) としての ClotoCore の登録。
v1.0 (2026-07-09) — 最初の標準。cpersona のポリシー議論から抽出し、語彙と規則を OSS の慣行 (Node.js のリリースフェーズ、React のリリースチャネル、 Debian の oldstable / Firefox ESR の猶予期間の前例、カーネルの stable ルール、 PEP 440) に照らしてベンチマークしました。