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://golang.org.tw/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 的一部分。