Go Wiki：MinorReleases

我們預設的決定應該是永不回溯，但對安全問題、沒有規避辦法的嚴重問題和文件修復的修復會被回溯到最近的兩個釋出分支（如果適用於該分支）。（例如，目前最新的兩個釋出分支是 release-branch.go1.16 和 release-branch.go1.17，從這些分支會生成新的 Go 1.16.x 和 Go 1.17.x 版本）實驗性埠的修復通常不會回溯。

“嚴重”問題是指會完全阻止程式執行的問題。

一旦相關方認為某個問題應該被考慮回溯，他們就會開啟一兩個“子”問題，標題格式為 package: title [1.17 backport]。問題中應包含原始問題的連結和一個簡短的說明，解釋為什麼可能需要回溯。

GopherBot 可以根據主問題中的以下評論自動打開回溯問題。（關鍵詞是 @gopherbot、backport、please，並且可以選擇性地加上釋出版本。整個訊息將被引用到新問題中。）

@gopherbot 請考慮將此問題回溯到 1.17，這是一個迴歸。

@gopherbot 請打開回溯跟蹤問題。這是一個嚴重的編譯器 bug。

修復會在主問題中開發，當修復合併到 master 分支後，主問題將被關閉。

子問題會被分配到 minor release milestone，並被打上 CherryPickCandidate 標籤，其候選資格會在那裡討論。一旦獲得批准，它將轉變為 CherryPickApproved。版本管理器（Go 團隊中負責版本流程的一部分）和/或程式碼所有者透過非正式流程批准 cherry-pick。

當子問題被打上 CherryPickApproved 標籤後，修復該問題的原始作者應立即建立並提交一個 cherry-pick 變更到釋出分支，該變更在準備好後即可合併，從而關閉子問題。

在釋出時，任何未被標記為 release-blocker 的未關閉回溯問題都將被推遲到下一個 minor release milestone，然後會生成一個 minor release，包含已合併的變更。

建立 cherry-pick CL

請注意，只有原始 CL 的作者和批准者才能建立 cherry-pick。

一旦主修復已提交到 master，請為適用的釋出分支建立一個 cherry-pick CL。

如果沒有合併衝突，您可以使用 Gerrit UI 建立 cherry-pick。

在彈出的視窗中輸入分支名稱（例如 release-branch.go1.10），新增提交訊息字首（例如 [release-branch.go1.10]），更新“Fixes”行，不要更改任何其他自動生成的行。

要從命令列進行 cherry-pick 或解決合併衝突，請記下最終的 commit hash，然後使用 git codereview 和 git cherry-pick 來準備一個 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

cherry-pick CL 必須包含類似 [release-branch.go1.10] 的訊息字首，並更新“Fixes”行為子問題。請勿更改或刪除“Change-Id”行或其他 Gerrit 行。

程式碼審查流程與其他常規 CL 相同。提交到釋出分支的許可權更為嚴格。如果您沒有提交許可權，那麼一旦您的 CL 準備就緒，版本管理器將為您提交。如果您有許可權，請務必在相應的 issue 被標記為 CherryPickApproved 之前不要提交 CL。

目前，無法透過傳送pull request來建立 cherry-pick CL。僅支援 Gerrit。請參閱 golang.org/issue/30037。

針對已 vendor 的 golang.org/x 包的 Cherry-pick CL

Go 標準庫包含一些生成的檔案，這些檔案的來源在主倉庫之外，在 golang.org/x 倉庫中。例如，golang.org/x/sys/unix 包的副本被vendor到 Go 樹中，golang.org/x/net/http2 包的副本被打包。這意味著對需要回溯到 Go release 的 golang.org/x 包的修復將需要兩個相應的 CL。

1. 在 golang.org/x 倉庫中，將修復從 master 分支 cherry-pick 到 internal-branch.go1.x-vendor 分支。

   提交訊息應包含“Updates golang/go#nnn”以提及回溯問題。

2. 在主倉庫的 release-branch.go1.x 分支上，建立一個 CL，該 CL 從 golang.org/x 的內部分支拉取修復。

   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。）