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