Go Wiki: MinorReleases

常にバックポートしないことがデフォルトの決定事項ですが、セキュリティ問題、回避策のない深刻な問題、およびドキュメントの修正に対する修正は、該当する場合、最新の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の作成者と承認者のみがチェリーピックを作成できることに注意してください。

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

マージの競合がない場合、Gerrit UIを使用してチェリーピックを行うことができます。

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

コマンドラインからチェリーピックを行うか、マージの競合を解決するには、最終的なコミットハッシュを記録し、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]のようなメッセージプレフィックスを含め、「Fixes」行を子イシューに更新する必要があります。「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パッケージのコピーはGoツリーにベンダー化されており、golang.org/x/net/http2パッケージのコピーはバンドルされています。つまり、Goリリースにバックポートする必要があるgolang.org/xパッケージの修正には、2つの対応するCLが必要になります。

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

   コミットメッセージには、バックポートイシューに言及するために「Updates golang/go#nnn」を含める必要があります。

2. 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.
   

   コミットメッセージには、バックポートイシューをクローズするために「Fixes #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でした。)