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

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	最新のリリースライン。リポジトリのフルのリリースゲートは通過済みですが、本番環境での認定はまだ受けていません。常にちょうど 1 つのラインが Current です。	すべてのバグ修正はまずここに入ります。開発が行われるのはこのラインです。
Candidate	すでに最新ではないものの、その認定 (§2.3) が決着していないライン — 後継の最初の final リリースが、自身の判断より先に到着したもの。どの配布チャネルもこれを配信せず (§4)、正確なバージョン指定でのみ到達できます。	クリティカル・セキュリティ・データ損失の修正は技術的に可能な限りバックポートされ、それ以外の修正はメンテナの裁量です。
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. ライフサイクル¶

flowchart TB
    pre["X.Y.0aN → X.Y.0bN → (必要なら X.Y.0rcN) → X.Y.0<br>Experimental"]
    cur["Current"]
    sta["Stable"]
    gra["Grace (30 日)"]
    eol["EOL"]
    cand["Candidate"]
    pre -- "リリースゲート通過" --> cur
    cur -- "freeze + 21 日の soak + 認定判断" --> sta
    cur -- "判断より先に後継の<br>最初の final リリースが到着" --> cand
    cand -- "認定判断" --> sta
    cand -- "後継が Stable に認定される<br>(このラインが認定されたか否かに関わらず)" --> gra
    sta -- "後継ラインが Stable に認証され、<br>この版は Grace に入る" --> gra
    gra --> 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) です。これは上のインストーラ opt-in 性質および §4 の配布マッピングと整合します。direct な final は、単に Current の最新リリースになるだけです。迷った場合は ladder を使ってください。

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

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

2.3 認定 (Stable への昇格)¶

認定は、期限付きの時計の上で行われる、メンテナの明示的な判断です (v1.4)。 v1.3 には時計がなく、その終わりの見えない soak によって、あるラインの欠陥記録が後継のリリースを足止めしていました。また Current の定義上、判断より先に置き換えられたラインに与えるティアがありませんでした。日付はすべて UTC の暦日です。

Freeze。 メンテナはラインの凍結を宣言します。これは日付を伴うイベントであり、リポジトリの SUPPORT.md のステータス表に記録されます。その日からラインは freeze 対象として適格な修正のみを受け入れます (§2.6)。フィーチャーリリースは、freeze を撤回させます。
Soak。 凍結されたラインは、リポジトリが明示した soak 環境 (cpersona の場合は本番の ClotoCore デプロイ) で 21 日間稼働します。評価の対象は、判断日時点でのそのラインの最新リリースです。
判断。 freeze + 21 日の時点で、メンテナは 2 つの結果のいずれかを記録します。soak 中に見つかったクリティカルまたは高深刻度の欠陥が、判断日時点で次のいずれかに該当しない限り、ラインは認定されます。まだ open であること、あるいはその修正がリリースされ soak 環境にデプロイされ、そこで少なくとも 7 日間観測されていないことです。

issue のクローズだけでは、どちらのテストも満たしません。認定されるのはデプロイされた成果物です。そうでない場合、判断は保留ではなく否定です。 4. 再審査 (最大 1 回)。 否定の判断から 14 日以内に、メンテナは再審査を宣言してもよい (MAY) です。2 度目の判断は宣言から 14 日後に、同じテストにより、指名された修正の差分検証として行われます。

修正が公開契約・既定値・データ形式・スキーマを変更する場合は、代わりにラインを再凍結します (新たな 21 日)。2 度目の否定の判断、あるいは 14 日以内に再審査が宣言されないことは、認定しないまま認定を決着させます。

認定は、そのラインが最新であることを要求しません。Candidate (§1) になったラインも、同じ時計で判断されます。より新しいラインが既に Stable である状態でラインが認定された場合、その認定は記録され、ラインは直ちに Grace に入ります。Stable の pin が後戻りすることは、決してありません (§4)。

認定日はステータス表に記録され、置き換えられた Stable ラインの grace ウィンドウを開始させます (§2.4)。一度も凍結されないラインが、認定されることはありません。後継が認定される時点で freeze が宣言されていない Candidate は、それと共に Grace に入ります。

2.4 Grace ウィンドウ¶

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

時計は認定イベントを起点とします。ウィンドウ内のパッチリリースはこれをリセットしません。
Candidate のライン (§1) — 遅れて認定された、認定されないまま決着した、あるいは一度も凍結されなかったもの — は、その後継が Stable に認定された時点で Grace に入り、同じ 30 日のウィンドウが適用されます。それまでは Candidate の修正ポリシーを維持します。サポートが取り下げられるのは、認定された代替が利用可能になったことによるのであって、そのライン自身の判断の結果によるのではありません。
複数のラインが同時に Grace にあってもよい (MAY)。各ウィンドウの終了日は開始時点で確定し、後の認定がそれを短縮することもリセットすることもありません。また認定は、それが直接置き換えるラインについてのみ Grace を開始させます。
ウィンドウ内に受理された問題の修正は、ウィンドウが閉じた後に出荷されることがあります。
移行がデータベーススキーマまたはデータのマイグレーションを必要とする場合 (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) は、freeze 対象として適格な修正のみを受け入れます。ある変更が freeze 適格であるのは、次の 3 つがすべて成り立つときです。正準の欠陥記録またはセキュリティ記録を参照していること、契約・ドキュメント・ freeze 前のリリースが確立した挙動を回復するものであること、そしてその挙動の回復に厳密に必要な範囲を超えて、ツール・オプション・レスポンスフィールド・既定値・サポート対象の構成・スキーマ・マイグレーションを追加しないことです。

それ以外のユーザーに見える変更は、規模に関わらずフィーチャーであり、次のラインを対象とします。「追加的」や「ロールバック安全」であることは、凍結されたラインへの入場を認めません。

修正リリースは 21 日をやり直させず、§2.3 の修正後 7 日間の観測を開始させます。フィーチャーリリース、あるいはそれ自体がロールバック安全でない修正は、 freeze を撤回させます。メンテナはそれを再宣言する (新たな 21 日) か、ラインを凍結しないままにします。 - 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)) ものの、コード中に単独で現れることは決してありません。

2.9 暫定パラメータとその見直し¶

21 日の soak、修正後 7 日間の観測、1 回限りの再審査とその 14 日のウィンドウ (§2.3) は、運用実績のないまま v1.4 で設定されたものです。

これらはライフサイクルに liveness を与えるスケジューリングのパラメータであって、測定された信頼度の閾値ではありません。1 つの soak 環境における経過時間は、サポート対象のあらゆる構成が試されたことを立証しません。認定が主張するのは、認定記録 (§3) が観測されたと述べていること、ちょうどそれだけです。

メンテナは、採用リポジトリ全体で最初の 2 回の認定試行が決着した後、あるいは 2027-03-01 のいずれか早い時点で、本標準の次の改訂においてこれらのパラメータを見直します。さらに、2 回連続で判断が否定となった場合、または再審査の後にラインが認定されないまま決着した場合には、それより早く見直します。トリガーが義務づけるのは見直しと結果の記録 (§8) であって、あらかじめ定まった変更ではありません。

2.10 緊急の pin ロールバックと認定取り消し¶

認定は記録されたイベントであり、書き換えられません。認定後に Stable のラインで重大な欠陥が表面化した場合、日付を伴う 2 つの別個のアクションがあります。

緊急ロールバックは、インシデント対応として既定の配布 pin を直前の認定済みラインへ戻すもので、ステータス表に記録され、修正が出荷された時点で元に戻されます。認定取り消しは、そのラインの Stable ステータスを取り下げ、その Grace ウィンドウを開始させます。いずれも、他方を含意しません。

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

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

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

判断ごとの認定記録 (v1.4) をステータス表からリンクします。記録が持つのは、凍結されたラインと評価対象の正確なリリース、freeze と判断の日付、soak 環境におけるデプロイのタイムスタンプ、soak 期間中のツール別または主要コードパス別の操作回数、試されたトランスポートと構成、コーパスの規模、そして試されていないと分かっている構成です。「認定済み」という語が指すのは、この記録です。

4. 配布マッピング¶

マーケットプレイス / ハブ: 既定の pin は Stable のラインを配信します。 pin が切り替わるのは認定時であって、リリース時ではありません。

チャネルの不変条件 (v1.4) はこうです。stable はちょうど 1 つのライン (EOL でない認定済みのうち最新のもの) に解決され、current はちょうど 1 つのライン (最新の final) に解決されます。§2.10 の緊急ロールバックによる場合を除き、いずれもより低いバージョンへ移動しません。Candidate のラインはチャネルを持たず、正確なバージョン指定でのみ到達できます。正確な pin やライン別の 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. パイロットの評価基準¶

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

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

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

7. 採用レジストリ¶

リポジトリ	標準バージョン	採用日	備考
cpersona	v1.4	2026-07-09	パイロット / リファレンス実装 (ポリシー運用)。最新の標準バージョンに追随します (正本の所在)。
ClotoCore	v1.3	2026-07-12	2 つ目のパイロット / リファレンス実装 (update-channel + 署名済みマニフェストのパイプラインによる構造的強制、`docs/RELEASE_PIPELINE_DESIGN.md`)。同リポジトリのマニフェストは、リリースのチャネルを pre-release サフィックスと `stable_line` のみから導出し、`current` は既に最新の final へ解決するため、v1.4 の Candidate ティアはパイプラインの変更を必要としません。この行は、当該リポジトリが freeze / 判断の語彙と認定記録を採用した時点で v1.4 へ移ります。

8. 変更履歴¶

v1.4 (2026-09-02) — 期限付きの認定 (§2.3): 日付を伴う freeze、21 日の soak、保留ではなく否定となる判断、issue のクローズではなくデプロイされた成果物に対するテスト、そして最大 1 回の再審査。判断より先に置き換えられたラインのための Candidate ティア (§1) により、後継の final リリースが先行ラインの認定を待つことはなくなりました。Grace は認定された代替の利用可能性に紐づけられ (§2.4)、freeze 適格な修正を定義し (§2.6)、見直し義務を伴う暫定パラメータを置き (§2.9)、緊急ロールバックと認定取り消しを別個の記録されるアクションとし (§2.10)、認定記録 (§3) とチャネルの不変条件 (§4) を導入しました。cpersona 2.5.x で表面化しました。そこでは終わりの見えない soak が 2.6.0 のリリース日を 2.5.x の欠陥記録に結びつけ、Current の「最新のライン」という定義により、2.6.0 が出荷された時点で 2.5.x に与えるティアがありませんでした。Node.js の予定された LTS 移行、既知のリグレッションを抱えたまま出荷しつつクリティカルな欠陥は排除する Linux と Rust のリリース慣行、 Debian の oldstable の重なり、および RFC 6410 による未観測のレビュー規則の削除に照らしてベンチマークしました。
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) に照らしてベンチマークしました。