Go Wiki: マイナーリリース

デフォルトの決定は常にバックポートしないことですが、セキュリティの問題、回避策のない深刻な問題、およびドキュメントの修正は、該当するブランチの場合、最新の2つのリリースブランチにバックポートされます。（たとえば、最新の2つのリリースブランチはrelease-branch.go1.16とrelease-branch.go1.17で、そこから新しいGo 1.16.xとGo 1.17.xのリリースが作成されます）実験的なポートの修正は、一般的にバックポートされません。

「深刻な」問題は、プログラムがまったく動作しなくなる問題です。

関係者が問題をバックポートの対象と考えるようになったらすぐに、package: title [1.17 backport]のようなタイトルの1つまたは2つの「子」の問題を開きます。この問題には、元の問題へのリンクと、バックポートが必要となる可能性のある理由に関する簡単な説明を含める必要があります。

GopherBotは、メインの問題に関する次のコメントに応答して、バックポートの問題を自動的に開くことができます。（キーワードは@gopherbot、backport、please、およびオプションでリリースです。新しい問題には、メッセージ全体が引用されます。）

@gopherbot 1.17へのバックポートを検討してください。これはリグレッションです。

@gopherbot バックポート追跡の問題を開いてください。これは深刻なコンパイラのバグです。

修正はメインの問題に対して開発され、修正がマスターブランチにマージされると閉じられます。

子問題はマイナーリリースの目標に割り当てられ、CherryPickCandidateラベルが付けられ、そこで候補が議論されます。承認されると、CherryPickApprovedに移行します。リリースマネージャー（リリースプロセスを処理するGoチームのサブセット）および/またはコード所有者は、非公式のプロセスでチェリーピックを承認します。

子問題にCherryPickApprovedラベルが付いたら、その問題を修正した変更の元の作成者は、すぐにチェリーピック変更を作成してメールで送信する必要があります。これはリリースブランチに対して行われ、準備が整い次第マージして子問題を閉じることができます。

リリース時には、リリースブロッカーではない未解決のバックポートの問題は次のマイナーリリースの目標にプッシュされ、すでにマージされた変更を含むマイナーリリースが作成されます。

チェリーピックCLの作成

元のCLの作成者と承認者のみがチェリーピックを作成できます。

メインの修正がマスターに送信されたら、該当するリリースブランチにチェリーピックCLを作成してください。

マージの競合がない場合は、Gerrit UIを使用してチェリーピックを作成できます

Top right corner > More > Cherry-pick

ポップアップでブランチ名（release-branch.go1.10など）、コミットメッセージプレフィックス（[release-branch.go1.10]など）を入力し、「修正」行を更新し、その他の自動化された行は変更しないでください。

コマンドラインからチェリーピックを行う場合、またはマージの競合を解決するには、最終的なコミットハッシュを書き留めてから、git codereviewとgit cherry-pickを使用してチェリーピックCLを準備します

git checkout release-branch.go1.17
git codereview change cherry-pick-NNNN
git cherry-pick $COMMIT_HASH
git commit --amend # add message prefix and change Fixes line
git codereview mail

チェリーピックCLには、[release-branch.go1.10]のようなメッセージプレフィックスを含める必要があり、「修正」行を子問題に更新します。「Change-Id」行やその他のGerrit行を変更または削除しないでください。

コードレビューのプロセスは、通常のCLと変わりません。リリースブランチへの提出権限はより制限されています。提出権限がない場合は、CLが準備できたら、リリースマネージャーが代わりに提出します。権限がある場合は、対応する問題がCherryPickApprovedとマークされるまで、CLを提出しないでください。

現時点では、プルリクエストを送信してチェリーピックCLを作成することはできません。Gerritのみがサポートされています。golang.org/issue/30037を参照してください。

ベンダーされたgolang.org/xパッケージのチェリーピックCL

Go標準ライブラリには、真の情報源がメインリポジトリの外、golang.org/xリポジトリにあるいくつかの生成されたファイルが含まれています。たとえば、golang.org/x/sys/unixパッケージのコピーはベンダー化されており、golang.org/x/net/http2パッケージのコピーはバンドルされています。つまり、Goリリースにバックポートする必要があるgolang.org/xパッケージへの修正には、2つの対応するCLが必要になります。

golang.org/xリポジトリで、masterブランチからinternal-branch.go1.x-vendorブランチに修正をチェリーピックします。

コミットメッセージには、「golang/go#nnnを更新」を含めて、バックポートの問題について言及する必要があります。
release-branch.go1.xブランチのメインリポジトリで、golang.org/x内部ブランチから修正を取り込むCLを作成します。
```
go get golang.org/x/repo@internal-branch.go1.x-vendor
go mod tidy
go mod vendor
go generate -run=bundle std  # If a bundled package needs regeneration.
```
コミットメッセージには、「#nnnを修正」を含めて、バックポートの問題を閉じます。

（Go 1.16以降、golang.org/xブランチ名は常にinternal-branch.go1.x-vendorです。Go 1.15では、golang.org/xブランチの名前は特別なケースでrelease-branch.go1.xまたはrelease-branch.go1.x-bundleです。）

このコンテンツはGo Wikiの一部です。