Go Wiki: 移植策略

引言

本文档介绍了将新的移植版本添加到 Go 主存储库的策略。移植版本是指操作系统 + 架构的组合，例如 linux/386。

本策略的目的是阐明 Go 项目在移植版本方面试图承诺的内容，并避免累积不完整或损坏的移植版本。

新移植版本的要求

在任何与移植版本相关的代码可以添加到 Go 主存储库之前，必须完成以下所有事项：

必须提交并接受一个提案，其中 Go 团队接受了在新移植版本添加到 Go 核心树方面的总体责任。通常，每个新的移植版本除了直接维护外，还会带来额外的维护成本。该成本因移植版本而异，取决于新移植版本与现有版本的相似程度。该成本必须由潜在的新用户或 Go 的新用例形式的整体效益来平衡。
必须指定（并同意）至少两名开发人员来维护该移植版本，他们将及时进行必要的更新，以应对架构或操作系统要求的变化。
- 移植版本维护人员列在 @golang/port-maintainers 的子团队中。要添加或删除现有移植版本的维护人员，请提交一个 issue。
- 特定于某个移植版本的更改，通常应首先由移植版本维护人员之一进行审查（当然，不能是编写更改的人）。我们目前要求每次更改都有两次审查，因此更改通常仍会由不熟悉移植版本细节的人进行审查，但理想情况下，这将是一次更随意的审查。
必须指定（并同意）一名开发人员来维护构建器，即测试每个 git 版本并为 https://build.golang.org 提供数据的机器。
- 构建器维护人员列在 x/build/dashboard/builders.go 中。要更新构建器的所有者，请向该文件发送更改。
构建器必须已在运行（并且失败，因为代码尚未添加到主存储库）。
所有成功运行 all.bash 所需的 CL 必须已发送进行审查。通常，这将是少量 CL，按其所更改的代码树部分进行划分。

一旦满足这些条件，Go 团队就可以接受移植版本并开始合并 CL。一旦所有 CL 都已提交，all.bash 必须通过，以便构建器在仪表板中报告“ok”。

其他存储库

虽然它不是核心存储库的一部分，但 x/sys 存储库应在发布前添加对新移植版本的支持，因为它添加新系统调用的官方位置。在主存储库工作之前，在 x/sys 存储库中添加对新移植版本的支持是可以的。

一流的移植版本

一些移植版本被认为是“一流的”。这种区别主要与发布有关。

一流的移植版本具有以下特性：

损坏的构建会阻止发布
- 所有贡献者都对这些移植版本负有责任（你弄坏了，你就修好它，或者找能修好的人。）
- 需要 Google 的 Go 团队来拥有构建器机器
安装说明文档位于 https://go-lang.org.cn/doc/install

将移植版本“升级”为“一流”由 Google 的 Go 团队酌情决定，并需要一个被接受的提案。

当前的一流移植版本是：

darwin/amd64
darwin/arm64
linux/386
linux/amd64
linux/arm
linux/arm64
windows/386
windows/amd64

所有 Linux 一流的移植版本都适用于使用 glibc 的系统。使用其他 C 库的 Linux 系统不支持，也不被视为一流。

维护移植版本

通常，更改 Go 工具和标准库的人员不得破坏上面列出的任何一流移植版本。破坏一流移植版本的更改必须修复或回滚。

破坏二级移植版本的更改不一定会回滚。如果存在某种破坏二级移植版本的合理可能性，鼓励开发人员确保移植版本继续正常工作（例如，通过运行特定于移植版本的 trybots）。还鼓励开发人员通知二级移植版本的维护人员任何可能的特定于移植版本的问题，他们可以通过联系相应的 GitHub 团队来做到这一点。也就是说，最终移植版本的维护人员负责使其移植版本正常工作。

损坏的移植版本

如果一个移植版本停止工作，包括构建器停止工作的这种情况，我们可以决定将其标记为损坏。
- 或者在某些情况下，我们可以回滚导致其损坏的更改；这是一个判断问题。
一般来说，如果一个移植版本的构建器在开发周期中多次失败，并且其失败模式不会发生在了一流移植版本上，并且该失败模式不被认为是 Go 存储库或构建器配置中的更改所修复或抑制，并且维护人员没有积极地致力于解决方案，那么该移植版本就可以被认为是损坏的。
任何审批者都可以宣布符合这些标准的移植版本是损坏的。
如果一个移植版本在 1.N 版本中损坏，那么 Go 核心团队可以选择将其从 1.(N+1) 版本中移除。
- 这不是强制性的，并且取决于是否有人愿意并有能力继续维护该移植版本。

这里的目标不是要将移植版本从树中移除；如果有人积极地维护移植版本，他们应该有尽可能多的自由来修复它。移除一个曾经工作过的移植版本应该是最后的手段。寻找新的维护者总是更好的选择。

移除旧操作系统和架构版本

为了让开发工作能够集中在 Go 用户广泛可用的系统上，随着时间的推移，我们可能会移除对旧操作系统和架构的支持，特别是旧的操作系统版本和架构修订版。

决定是否移除对旧操作系统或架构版本的支持时，重要的考虑因素是：

可用性。 如果操作系统不再分发或硬件不再制造，例如，就没有明确的必要继续支持。例如，Go 的 ppc64 移植版本不再支持 IBM POWER5 架构。
制造商支持。 如果操作系统或架构不再由其制造商支持，这是一个强烈的信号，表明未来版本的 Go 也可以移除支持。例如，苹果公司每年通常会发布一个新版本的 macOS 并弃用一个旧版本。Go 通常以相同的速度弃用旧的 macOS 版本。
实际或预期的用户群。 如果用户相对较少，维护移植版本的大量工作可能不值得。
持续成本。 需要大量持续调试或实施工作的移植版本将比不需要的移植版本受到更严格的审查。

当上述考虑因素有利于移除移植版本并且提案被接受时，Go 1.N 的发布说明将宣布对某个操作系统或架构的支持将在 Go 1.(N+1) 中删除。

入门

有关如何编写新移植版本的讨论，请参阅 https://groups.google.com/forum/#!topic/golang-dev/SRUK7yJVA0c。

意见和问题

有关该政策的意见或问题应发送至 golang-dev。

此内容是 Go Wiki 的一部分。