リリースエンジニアリングポリシー

5 つのポリシーが apothem のリリース方法を規定します。

1. セマンティックバージョニングCopy Anchor Link

本プロジェクトはセマンティックバージョニング 2.0に従って出荷されます。 バージョン番号は MAJOR.MINOR.PATCH[-PRERELEASE][+BUILD] の形式をとります。

候補タグは vX.Y.Z-rc.N（リリース候補） または vX.Y.Z-alpha.N / vX.Y.Z-beta.N（早期アクセス）の形式を使用します。

2. リリースタグCopy Anchor Link

すべてのリリースは、vMAJOR.MINOR.PATCH 形式の署名付き git タグを main 上に配置します。 このタグは .github/workflows/release.yml をトリガーし、このワークフローがビルド、署名、SBOM と SLSA-3 来歴の生成を行い、GitHub Release ページを公開します。

タグの規約:

• 形式 — 正確に vMAJOR.MINOR.PATCH です。release- の接頭辞も、 -final の接尾辞も付けません。
• 注釈 — すべてのタグは注釈付きタグ（git tag -a -s）であり、 タグメッセージにリリースノートの要約を含みます。
• 署名 — すべてのタグは GPG 署名されます。リリースワークフローは、さらに、 各アーティファクトに対する Sigstore のキーレス cosign 署名と、SLSA-3 来歴記録を生成します。 どちらも GitHub Release ページに添付されます。

リリースモデル: 追加型Copy Anchor Link

リリースは追加型です。 各リリースは main に 1 つのコミットと 1 つのタグを追加します。main が強制プッシュされることは決してなく、公開済みのタグ、GitHub Release、npm バージョンが削除、移動、再利用されることもありません。 各リリースはそれぞれのタグ、GitHub Release、npm バージョンを保持し、すべてが公開されたままです。 npm のバージョンは不変です。公開済みの name@version は決して置き換えられず、公開が取り消された番号は二度と使用できません。 ピン留めされたインストールと再現可能なビルドは、すべての公開済みタグに依存しています。 リリースサイクルランブックとリリース復旧ランブックは、どちらもこのモデルに従います。

リポジトリのリリースファサードルール（コントリビューター向け指示の Release Facade セクション）は、このモデルを述べています。 「現在のバージョンのみ」という要件は、鮮度ファサードルールにも反映されており、公開面が示す内容を対象とします。 このルールは、どのリリースが公開されたままになるかを制限するものではありません。

3. 非推奨化ポリシーCopy Anchor Link

現在の公開サポートラインは、最新のリリース済みマイナーです。 プロジェクトに複数の公開マイナーがある場合、SECURITY.md のサポート対象バージョンマトリクスが、追加の重要修正のみのサポート期間に関する信頼できる情報源です。

非推奨化の周期:

• 告知 — 非推奨となるシンボルや動作は、その非推奨化が含まれるリリースの CHANGELOG.md の ### Deprecated セクションで告知されます。 リリースノートはこの非推奨化の告知を反映します。
• 猶予期間 — 非推奨のシンボルは、削除される前に最低でも 1 つの完全なマイナーサイクルの間、利用可能なまま残ります。
• 削除 — 削除は MAJOR の引き上げで行われます。削除された各シンボルには、 CHANGELOG.md の ### Removed 行と、 ハウツーガイド配下の移行ガイドのエントリが付きます。

ランタイムの下限Copy Anchor Link

Apothem は 2 つのランタイムの下限を宣言しています。 pyproject.toml の requires-python = ">=3.10" と、package.json の "engines": {"node": ">=18"} です。

• 宣言されたすべての下限はテストされます。 Python の下限は、CI の quality マトリクスと CI Matrix ワークフローで実行されます。npm Shim ワークフローは、 Node の下限と、それ以降のすべての LTS メジャーバージョンで npm シムを実行し、 前提条件が欠けているときのエラー、node bin/apothem.mjs --version、 隔離されたホームディレクトリでのドライランインストール、そして npx を介したパック済み tarball をチェックします。 テストされていないランタイムは宣言されません。
• サポート終了は開示されます。 まだ宣言された下限であるランタイムが上流でサポート終了を迎えた場合、 インストールガイドがその旨を記載し、 優先すべきバージョンを示します。Python 3.10 は 2026-10-01 にサポート終了を迎え、 Node.js 18 と 20 はそれぞれ 2025-04-30 と 2026-04-30 に迎えました。 3 つとも引き続きサポートされる下限です。
• 下限の引き上げは非推奨化です。 上記の周期に従います。 ### Deprecated での告知、古い下限が引き続きテストされる少なくとも 1 つの完全なマイナーサイクルを経て、 下限を引き上げるリリースがその変更を記録します。 requires-python、engines.node、インストーラーのバージョンプローブ、CI マトリクスは、 そのリリースで一緒に変更されます。

4. 互換性のない変更のポリシーCopy Anchor Link

互換性のない変更には以下が必要です。

1. RFC イシュー — rfcs イシューラベルで作成され、 互換性のない変更、移行パス、ロールバック戦略を記述したもの。
2. 30 日間のコメント期間 — RFC はマージ前に少なくとも 30 日間オープンのままにします。フィードバックが正当化する場合、 メンテナーはこの期間を延長できます。
3. MAJOR の引き上げ — 互換性のない変更を含むリリースは、 MAJOR コンポーネントを引き上げます。
4. 移行ガイド — 変更には、オペレーターに移行の手順を案内する ハウツーガイドのエントリが付属します。

5. ロールバックポリシーCopy Anchor Link

リリースが採用を妨げるリグレッションを示した場合:

1. リバート — 問題のあるコミットが main 上でリバートされます。
2. 前方修正リリース — 後続のリリースが vMAJOR.MINOR.PATCH+1 として配置され、リバートと付随する増分修正を含みます。 以前の不良リリースは GitHub Releases から削除されず、その npm バージョンは公開されたままとなり （npm のバージョンは不変です）、npm deprecate で印が付けられます。 CHANGELOG.md の ### Yanked 注釈がこの状況を記録し、 再現可能なビルドがアンカーされたまま保たれるようにします。
3. コミュニケーション — ロールバックには、security-advisories の通知 （セキュリティに関連する場合）、またはインシデント用にピン留めされた GitHub イシュー （信頼性に関連する場合）が付随します。

関連項目Copy Anchor Link

• CHANGELOG.md — 正規のリリース台帳。
• SECURITY.md — サポート対象バージョンマトリクスと報告チャネル。
• cicd-pipeline.md — すべてのリリースを ゲートする CI チェックのクラス。
• deployment-checklist.md — リリースごとの 本番準備スイープ。