> For the complete documentation index, see [llms.txt](https://summerain-1.gitbook.io/summerain/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://summerain-1.gitbook.io/summerain/ja/dokyumento/releasing.md).

# リリースとタグ管理

`VERSION` は正式なプロジェクトリリースにおける唯一の信頼できる情報源です。 通常のコードコミットでは開発用イメージのみが更新され、`main` または `master` 上のコミットで `VERSION` が変更された場合に限り、正式リリースが作成されます。

## タグ規則

| シナリオ                         | 入力バージョン      | コンテナタグ                                                   |
| ---------------------------- | ------------ | -------------------------------------------------------- |
| `main` / `master` への通常の push | バージョン変更なし    | `edge`、`sha-<short-commit>`                              |
| 安定版リリース                      | `1.2.3`      | `v1.2.3`、`1.2.3`、`1.2`、`1`、`latest`、`sha-<short-commit>` |
| プレリリース                       | `1.3.0-rc.1` | `v1.3.0-rc.1`、`1.3.0-rc.1`、`sha-<short-commit>`          |

`vX.Y.Z`、`X.Y.Z` およびそれらのプレリリース形式を含む正確なバージョンタグは、 決して上書きしてはいけません。`latest`、`X`、`X.Y` は移動可能なエイリアスで、 安定版をリリースするたびに、対応する互換範囲内の最新バージョンを指します。

## リリース手順

1. `main` でフロントエンドとバックエンドのチェックが成功していることを確認します。
2. 下記の厳密な形式に従って新しいバージョンを選びます。過去のバージョン番号を 再利用してはいけません。
3. `VERSION` の変更だけを、`chore: release vX.Y.Z` というメッセージで コミットします。
4. コミットを push し、`CI and Docker` の完了を待ちます。
5. GitHub Releases、Docker Hub、GHCR のバージョンタグとマルチプラットフォーム マニフェストを検証します。また、Docker Hub のリポジトリ説明にルートの `README.md` が同期されていることも確認します。

例：

```bash
printf '1.2.3\n' > VERSION
git add VERSION
git commit -m "chore: release v1.2.3"
git push origin HEAD:main
```

## バージョンの選択

* Patch：後方互換性のある不具合修正。例：`1.2.3` から `1.2.4`。
* Minor：後方互換性のある新機能。例：`1.2.3` から `1.3.0`。
* Major：互換性のない変更。例：`1.2.3` から `2.0.0`。
* Pre-release：`2.0.0-rc.1` などの候補版。安定版エイリアスは更新しません。

`VERSION` は SemVer 2.0.0 の core および pre-release 構文に従います。major、 minor、patch、ならびに数字だけのプレリリース識別子に先頭ゼロを付けてはいけません。 したがって `1.2.3` と `1.2.3-rc.1` は有効ですが、`01.2.3` と `1.2.3-01` は無効です。Docker タグでは `+` を損失なく表現できないため、 プロジェクトのリリースバージョンでは build metadata を使用できません。 `v<version>` が Docker の 128 文字というタグ上限内に収まるよう、バージョンは 最大 127 ASCII 文字です。コミット前に `bash scripts/validate-release-version.sh "$(< VERSION)"` を実行してください。

`main` / `master` のイメージ公開が成功するたびに、`dockerhub_metadata` Job は ルートの `README.md` を `jaykserks/summerain` へ同期します。正確なタグを push する前とメタデータ公開時に不変タグポリシーを更新するのは正式リリースだけです。 ポリシーヘルパーは Docker Hub 管理 API の一時的な 5xx 応答に対して回数を制限した 再試行を行います。`latest`、`X`、`X.Y`、`edge`、コミットタグは不変ルールに 一致しないため、上記ポリシーに従って引き続き移動できます。

正式リリースを再実行すると、ワークフローは Docker Hub と GHCR にある正確な バージョンタグの registry descriptor digest を読み取ります。いずれかの registry に `vX.Y.Z` または `X.Y.Z` がすでに存在すれば、そのダイジェストを復旧元とします。 ワークフローは両方の registry で不足している正確なタグを補い、`latest`、`X`、 `X.Y`、今回の `sha-<commit>` を同じダイジェストへ向け直します。既存の不変タグを 再ビルドまたは上書きすることはありません。registry 内または registry 間で正確な タグのダイジェストが一致しない場合、ワークフローは失敗して手動調査を求めます。 どのイメージが正しいかを推測することはありません。

これらの Docker Hub 操作は、リポジトリ Secrets の `DOCKERHUB_USERNAME` と `DOCKERHUB_TOKEN` を共用します。トークンには、イメージの push、タグポリシーの 設定、リポジトリ説明の更新に使用する `read/write/delete` 権限が必要です。

## サプライチェーンの固定

ワークフロー内のすべてのサードパーティ GitHub Actions は、完全な commit SHA に 固定されています。行末コメントには対応するメジャーバージョンを記録しています。 Action を更新する際は、上流 release と新しい SHA の両方を確認してください。

`requirements.lock` は、`linux/amd64` と `linux/arm64` の両方をサポートする必要が あるサービスイメージを、正確なバージョンタグで記録します。プラットフォーム固有の child manifest digest はアーキテクチャ間で移植できないため、共有ロックファイルには 記録しません。本番デプロイをダイジェストで固定する場合は、公開された OCI index / manifest-list digest を使用してください。

## ロールバック

正確なバージョンタグを移動または再利用してはいけません。ロールバックするには、 `DOCKER_IMAGE` を動作確認済みの正確なバージョンまたは OCI マルチプラットフォーム インデックスダイジェストに設定し、`--no-build` で再デプロイします。問題を修正した後、 新しい Patch リリースを公開してください。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://summerain-1.gitbook.io/summerain/ja/dokyumento/releasing.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.