Go Wiki: Go-Release-Cycle

本 Wiki 頁面由 Go 團隊維護。請 傳送評論到 golang-dev 或 提交 issue，而不是直接進行更改。

短連結：https://golang.org.tw/s/release。

概覽

Go 每六個月釋出一次。每個釋出週期分為大約 4 個月的開發階段，然後是 3 個月的測試和完善期，稱為釋出凍結期。如果一切順利，在上一版本釋出之前就會開始下一版本的開發工作，從而導致大約一個月的重疊期。

版本初始釋出後，將透過修復嚴重 bug 和安全問題的次要版本進行支援。

時間線

當前的釋出週期安排在每年 1 月中旬和 7 月中旬開始。釋出週期的目標里程碑如下所述。我們儘量貼近目標，同時仍交付高質量的版本。

為了給團隊留出準備時間和處理意外問題，我們傾向於在週中或週中早期進行釋出工作。這意味著具體日期每年都會有所不同，因此里程碑是按特定月份的周來指定的。第 1 周是指從當月第一個星期一開始的那一週。所有日期都可能根據當年的假期安排而變化。

1 月/7 月第 1 周：開始釋出規劃。

即將到來的釋出週期的主要工作規劃將在 golang-dev 上宣佈。

示例：Go 1.20

1 月/7 月第 3 周：開始釋出工作。

在上一版本進入最終穩定期後，程式碼樹將對通用開發開放。在此期間歡迎各種開發。最好是大型或特別有風險的更改在開發視窗結束前較早合併，以便有時間修復隨之出現的問題。

5 月/11 月第 4 周：開始釋出凍結。

此里程碑標誌著釋出週期的第二部分，即釋出凍結。釋出凍結適用於整個主儲存庫以及構建釋出中所包含的二進位制檔案所需的子儲存庫中的程式碼，特別是 vet 及其在 tools 子儲存庫中的所有依賴項。

在此凍結期間，只接受 bug 修復、僅測試更改和文件更新。偶爾也可能在凍結期間進行新的工作，但僅限於特殊情況，並且通常僅當工作在截止日期之前已提出並獲得批准的情況下。此類更改必須風險較低。請參閱下面的 凍結例外。

釋出週期的這一部分專注於透過測試和修復發現的 bug 來提高版本的質量。但是，必須評估每個修復，以權衡潛在修復的好處與將未經充分測試的程式碼（即修復）納入釋出的成本。在釋出週期的早期，傾向於接受修復。在釋出週期的後期，傾向於拒絕修復，除非能夠證明該修復的風險低且回報高。

在週期後期適合進行的低風險更改的示例包括對文件的更改以及對當前版本中引入的新功能的修復（因為不會出現與早期版本相比的迴歸）。

凍結開始後不久，幾乎所有已知 bug 都應已修復或明確推遲（推遲到下一個版本或無限期推遲）。剩餘的 bug 通常應被跟蹤為釋出阻塞項並緊急處理。

6 月/12 月第 2 周：釋出候選版 1 釋出。

釋出候選版旨在儘可能接近最終釋出版本。釋出候選版的釋出表明 Go 團隊對程式碼樹沒有關鍵 bug 抱有高度信心。特別是，由於 Google 會持續跟蹤 Go 的開發版本，因此在釋出候選版釋出時，其近似版本至少已在 Google 的生產環境中運行了一到兩週。

釋出候選版釋出後，只應進行文件更改和修復關鍵 bug 的更改。總的來說，此時 bug 修復的標準比次要版本中的 bug 修復標準還要高。我們可能寧願釋出一個已知但很少見的崩潰版本，也不願釋出一個包含新但未經生產環境測試的修復的版本。

如果報告並修復了關鍵 bug，可能會發布其他釋出候選版，但通常每兩週不超過一個。

再次強調，釋出候選版應儘可能做到無 bug。鼓勵組織在經過適當的組織特定測試後將其部署到生產環境。

釋出候選版與最終釋出之間的平靜期是進行額外測試或討論下一個版本（請參閱上面的規劃里程碑）的好時機。

7 月/1 月第 3 周：開始下一版本的工作

在當前版本穩定化的同時，下一版本的工作也將開始。在此期間，旨在用於當前版本的修復需要 挑選到釋出分支。與次要版本的挑選不同，這些更改不需要 backport issue，也不需要釋出團隊批准。只要它們符合 凍結策略，就可以像任何其他 CL 一樣進行稽核和提交。

8 月/2 月第 2 周：釋出。

最終，釋出本身！

釋出不應包含自上次釋出候選版以來的重大更改：所有釋出程式碼都經過充分測試這一點很重要。釋出標誌著釋出測試已確認釋出候選版對程式碼樹沒有關鍵 bug 抱有高度信心。

即使釋出順利且有空餘時間，我們也傾向於按計劃進行。額外的測試只能提高版本的穩定性，並且還能讓負責 Go 版本開發的開發人員在程式碼更改再次湧入之前，有更多時間思考和規劃下一個版本。

到最終釋出時，Google 將已使用此版本的 Go 近兩個月。雖然 Google 的成功使用並不保證沒有問題，但我們的經驗表明，它確實有助於提高版本的質量。我們強烈鼓勵其他組織儘可能積極地測試釋出候選版，並報告發現的問題。

一旦版本穩定下來，就可以開始下一版本的工作，包括程式碼審查和新程式碼的提交，然後迴圈重複。請注意，如果釋出延遲，下一版本的工作也可能延遲。

版本維護

釋出次要版本是為了解決一個或多個沒有變通方法（通常與穩定性和安全性相關）的嚴重問題。版本中包含的唯一程式碼更改是針對特定嚴重問題的修復。重要的僅文件更改和安全的測試更新（例如停用測試）也可能包含在內，但僅此而已。次要版本儘可能保留向後相容性，並且不引入新 API。

針對 Go 1.x 的問題（包括安全問題）的次要版本釋出，將在 Go 1.x+2 版本釋出後停止。有關安全更新的更多資訊，請參閱 安全策略。

另請參閱 MinorReleases Wiki 頁面。

凍結例外

符合 凍結策略 的修復 CL 不需要凍結例外。

凍結的任何例外情況必須在凍結之前與 Go 釋出團隊溝通並獲得明確批准。如果您想請求例外，請在 issue tracker 中提交一個 issue，並在後面加上“[freeze exception]”字尾，幷包含“CC @golang/release”（示例）。我們將逐個處理任何請求，並強烈傾向於不允許在凍結後進行更改。

歷史說明

此計劃的一個版本，開發視窗較短，最初於 2016 年為 Go 1.7 釋出採用。經過多年的艱難釋出，2022 年和 2023 年的測試和流程改進促成了及時的 1.19 釋出。對於 1.20，透過延遲凍結和提前解凍來擴充套件了開發視窗。這些更改已正式化用於 1.21 釋出。我們預計將繼續按時釋出。