SPECIFICATION

第 10 章 バージョン管理

権威ある情報源の宣言（Single Source of Truth）。 DTP バージョン管理の方針は、第 1 章 §1.7「バージョン管理と互換性」を唯一の権威ある情報源とする。本章は §1.7 が既に定めた方針を再定義 してはならない。本章は §1.7 規則の操作的機構（ワイヤフォーマットのバインディング、エラーコードの具体的なペイロード、ネゴシエーション時系列、実装宣言テンプレート）とガバナンスフロー（ディレクトリとステータスの規約、確定の標準アクション）のみを提供する。本章のいかなる記述も §1.7 と曖昧さが生じた場合、必ず §1.7 を優先 しなければならない。

10.1 バージョン番号の形式（操作的参照）

DTP プロトコルバージョン番号の意味論、2 レベルの MAJOR.MINOR 構造（PATCH なし）、変更判定規則、直交軸の定義は §1.7.1 および §1.7.2 にあり、本章では繰り返さない。

ワイヤフォーマットのバインディング：各 LogicalFrame のフレームヘッダーは完全な ProtocolVersion フィールドを携帯 しなければならない（第 4.4 節を参照）：

interface ProtocolVersion {
  major: number;  // 非負整数
  minor: number;  // 非負整数
}

本仕様で定義されるプロトコルの初期バージョンは { major: 1, minor: 0 }（すなわち dtp/1.0）で なければならない。

10.2 バージョン互換性マトリックス（§1.7.3 の操作的補足）

互換性とネゴシエーションの規範的規則は §1.7.3 にある。以下の表はフレーム処理レベルでのその操作的な落とし込みであり、§1.7.3 に従って読ま なければならない。曖昧さがある場合は §1.7.3 を優先する。

受信フレームのバージョン処理方法
受信側の最高バージョンと等しい通常処理
受信側の最高バージョンの直前のメジャーバージョンと等しい（major - 1）互換処理（旧仕様に従って処理）
受信側の最高バージョンより高いVERSION_INCOMPATIBLE（7001）を返 さなければならない
(受信側の最高バージョン - 1) より低いメジャーバージョンVERSION_INCOMPATIBLE（7001）を返 さなければならない
同じメジャーバージョン、より低いマイナーバージョン通常処理（後方互換）
同じメジャーバージョン、より高いマイナーバージョン処理 すべきである（認識しない任意フィールドは無視する）

10.2.1 マイナーバージョン番号の容錯（§1.7.3 の操作的落とし込み）

実装が同じメジャーバージョン番号で、より高いマイナーバージョン番号のフレームを受信した場合、以下を しなければならない：

  1. 既知のフィールドを処理する；
  2. 未知の任意フィールドは無視 すべきである；
  3. 未知の任意フィールドを理由にフレーム全体を拒否 してはならない；
  4. エラーをスロー してはならない。

10.3 バージョン非互換の処理（操作機構）

10.3.1 受信側の処理

受信側がプロトコルバージョン番号が自身のサポートバージョンより高い（かつ互換範囲を超える）LogicalFrame を受信した場合、以下を しなければならない：

  1. そのフレームを 処理しない；
  2. 送信側に VERSION_INCOMPATIBLE エラー（7001）を送信する；
  3. エラー通知の details フィールドに自身がサポートする最高バージョン番号を含める：
{
  errorCode: 7001,
  errorMessage: "Protocol version higher than supported",
  details: {
    supportedMaxVersion: { major: 1, minor: 0 }
  }
}

エラーコード 7001 の意味論は第 9 章のエラーコード表と schema を基準とし、本章では別途定義しない。

10.3.2 送信側の処理

送信側は VERSION_INCOMPATIBLE エラーを受信した後、以下を選択 してもよい：

  1. 対端がサポートするバージョンにダウングレード してそのフレームを再送する（優先すべき。ただし双方に共通の MAJOR が存在することが前提；MAJOR をまたぐダウングレードは行わない、§1.7.3 を参照）；
  2. 上位アプリケーションに通知 してバージョン非互換を伝える。自動的に再試行を継続 してはならない。

実装はバージョン非互換エラーを受信した後、即座にセッションをクローズ してはならず、ダウングレードの機会を与える べきである。

10.3.3 セッション内バージョン一致性とネゴシエーション時系列

DTP セッション確立時、双方は一致するプロトコルバージョンをネゴシエート しなければならない（ネゴシエーション規則は §1.7.3 にある）。セッション期間中：

  1. ネゴシエーション後、セッション全体を通じて統一されたバージョンを使用 しなければならない；
  2. セッション進行中にプロトコルバージョンを切り替えて はならない。

バージョンネゴシエーションは以下の時系列に従う べきである。具体的な担持方式（CAP 拡張、最初の Request_Frame/Response_Frame など）は実装が選択 してもよい が、最初のデータフレームを送信する前に完了 しなければならない：

DTP_A                              DTP_B
  |                                   |
  |-- Hello (supported_versions) --->|
  |                                   |
  |<-- Hello_Ack (chosen_version) ---|
  |                                   |
  |    [双方が chosen_version を使用]  |

10.4 プロトコル進化とガバナンス

本節は §1.7 ガバナンス規則の操作フローを提供する。そこで言及される git tag 形式、ドキュメントステータス列挙、編集版次の定義は、§1.7 を規則アンカーと しなければならず、本節では再定義しない。

10.4.1 ディレクトリとステータスの規約（Faying Protocol と一致）

  • ドキュメントステータスは front matter のマーカーであり、パスに符号化 してはならない（§1.7.1 を参照）。
  • specification/ の下には、唯一の可変作業領域 draft/ のみを保持 しなければならない（ローリング更新）。
  • draft/ 以外のすべてのディレクトリは公開日付で命名 しなければならず（例：2025-10-25/）、凍結された 公開済みの版次を表す。「ドラフトでなければ公開済み」。
  • 公開済みの版次が現在 Final か Deprecated / Obsolete かは、もっぱら そのファイルの status フィールドによって決定され、ディレクトリ名から推測 してはならない。
  • ステータス名のディレクトリ（例：final/）の作成は 禁止 ——さもなければ版次を非推奨化する際にディレクトリの移動とリンクの破壊が必要になる。
  • WHEN ステータス遷移が発生した場合、もっぱら front matter の status を変更 しなければならず、ディレクトリは移動 してはならない。

10.4.2 ドラフトと正式バージョン

  • ドラフト：ドキュメントは docs/{lang}/specification/draft/ に、schema は schema/draft/ に格納する；ドラフトバージョン番号は { major: 0, minor: N } を使用 してもよい。Draft 期間中は互換性の約束は なく（§1.7.5 を参照）、ドラフトを本番環境で使用 してはならない。
  • 正式バージョン：完全なレビューと公開討議を経て、不変のバージョンスナップショットを有していなければ ならない；ドキュメントは docs/{lang}/specification/{YYYY-MM-DD}/ に、schema は schema/{YYYY-MM-DD}/ に格納する。最初の正式バージョンは 2025-10-25 であり、プロトコルバージョン dtp/1.0 に対応する。
  • バージョンスナップショットの不変性：正式バージョンは一旦リリースされたら不変を維持 しなければならない；純粋なテキスト正誤は §1.7.4 に従って新しい公開日付ディレクトリで担持し、既存のディレクトリは凍結され、公開済みスナップショットの仕様内容や schema をその場で書き換えて はならない。

10.4.3 確定の標準アクション（Draft → Final）

WHEN 確定を実行する場合、Doc Governance Process は以下のアクションを順に完了 しなければならない：

  1. git mv を使って draft/ 下のすべてのファイルを公開日付ディレクトリに移行し（ファイル名は不変）、draft/ を空にする；
  2. ファイルごとに status を Draft から Final に変更する；
  3. date を正式公開日付に固定し、editors を確定署名リストにロックし、version を不変に保つ；
  4. README front matter に replaces 履歴チェーン（ドラフトディレクトリおよびその確定コミットの短縮ハッシュを指す）を記入する；
  5. tag dtp-v<MAJOR.MINOR>-final を設定する。この tag は本文 + テストベクトル + schema を同時にカバー しなければならない；
  6. 複数言語 / 複数ファイルが関わる場合、同一のコミットでまとめて移行 しなければならず、一方的なリリースは 禁止 される。

10.4.4 非推奨化と削除

実装は以下のフローによって機能を非推奨化 すべきである：

  1. 非推奨としてマーク：MINOR バージョンで機能を deprecated としてマークするが、引き続きサポート しなければならない；
  2. 移行期間：少なくとも 1 つの完全な MAJOR バージョンサイクルを経る；
  3. 削除：次の MAJOR バージョンで削除する。

実装は MINOR バージョンで非推奨化された機能を削除 してはならない。

10.5 実装の宣言

DTP 実装は文書中で以下を宣言 しなければならない：

  1. サポートする最高プロトコルバージョン；
  2. サポートするすべての先行メジャーバージョン；
  3. 将来互換性をサポートするか（より高いマイナーバージョンのフレームを処理するか）；
  4. 実装定義の拡張（ある場合）。

例：

DTP 実装 X バージョン宣言：

  • サポートする最高プロトコルバージョン：1.0
  • 互換可能な先行バージョン：なし（最初の正式バージョン）
  • 将来互換性：サポートし、未知の任意フィールドは無視する
  • 暗号化アルゴリズム：AES-256-GCM、ChaCha20-Poly1305
  • 伝送アダプタ：BLE、WebSocket、TCP