版本模型

正如原始部落格文章中所宣布的那樣，Bazel 4.0 及更高版本支援兩種發布方式：滾動發布和長期支援 (LTS) 版本。本頁面涵蓋了 Bazel 發布模式的最新資訊。

支援矩陣

所有 Bazel LTS 版本都可以在 GitHub 的版本頁面上找到。

發布版本管理

Bazel 使用 major.minor.patch Semantic Versioning 方案。

• 主要版本包含的功能與先前版本不回溯相容。每個 Bazel 主要版本都是 LTS 版本。
• 次要版本包含回溯相容的錯誤修正和功能，這些修正和功能是從主要分支版本回溯移植。
• 修補程式版本包含重大錯誤修正。

此外，預先發布版會附加連字號和日期後置字串，標示為下一個主要版本。

舉例來說，如果每種型號都推出新版本，版本號碼會如下所示：

• 主要：6.0.0
• 次要版本：6.1.0
• 修補程式：6.1.2
• 預先發布版：7.0.0-pre.20230502.1

支援階段

每個主要 Bazel 版本都有四個支援階段：

• 推出中：這個主要版本仍處於預先發布階段，Bazel 團隊會從 HEAD 發布推出版本。
• 有效：這個主要版本是目前有效的長期支援 (LTS) 版本。Bazel 團隊會將重要功能和錯誤修正項目回溯移植到次要版本。
• 維護：這個主要版本是舊版 LTS 版本，目前處於維護模式。Bazel 團隊只承諾將安全性問題和 OS 相容性問題的重大錯誤修正項目，反向移植到這個 LTS 版本。
• 已淘汰：Bazel 團隊不再支援這個主要版本，所有使用者都應遷移至較新的 Bazel LTS 版本。

發布頻率

Bazel 會定期發布兩個發布途徑的版本。

滾動式發布

• 我們與 Google Blaze 版本協調發布時間，並大約每兩週從 HEAD 發布一次。這是下一個 Bazel LTS 版本的預先發布版。
• 因此可能包含不相容的變更。建議您針對重大破壞性變更使用不相容的標記，推出不相容的變更時，應遵守我們的回溯相容政策。

LTS 版本

• 主要版本：預計每 12 個月左右，會從 HEAD 推出新的 LTS 版本。新的 LTS 版本發布後，會立即進入「有效」階段，而先前的 LTS 版本則會進入「維護」階段。
• 次要版本：預計每 2 個月發布一次 Active LTS 軌的新次要版本。
• 修補程式版本：如果需要修正重大錯誤，我們預計會視需求發布新修補程式版本，適用於處於「有效」和「維護」階段的 LTS 版本。
• Bazel LTS 版本在維護階段 2 年後，就會進入淘汰階段。

如要瞭解預計發布時間，請查看 Github 上的版本問題。

發布程序和政策

如果是滾動式發布，程序很簡單：大約每兩週會建立新版本，與 Google 內部 Blaze 版本採用相同的基準。由於發布時間表快速，我們不會將任何變更反向移植到持續發布版本。

對於 LTS 版本，我們遵循下列程序和政策：

1. 判斷版本的基準提交。
   • 如果是新的主要 LTS 版本，基準提交內容就是主要分支的 HEAD。
   • 如果是次要版本或修補程式版本，基準提交內容是相同 LTS 版本目前最新版本的 HEAD。
2. 從基線提交建立一個名為 release-<version> 的發布分支。
3. 透過 PR 將變更移植到發布分支。
   • 社群可以在相關的 GitHub 問題或 PR 上回覆「@bazel-io flag」，將特定提交內容標示為潛在的發布阻礙，建議 Bazel 團隊將這些內容向後移植。Bazel 團隊會對這些內容進行分類，並決定是否要向後移植。
   • 只有主要分支上的回溯相容提交內容可以回溯移植，解決合併衝突的其他次要變更則可接受。

4. 使用 Cherry-Pick 向 Bazel 維護者提出請求，移植變更。

   • Bazel 維護人員可以要求將特定提交內容挑選至發布分支。這個過程透過在 GitHub 上建立 cherry-pick 請求來啟動。做法如下。

     1. 開啟 cherry-pick 請求
     2. 填寫請求詳情
        • 標題：請為請求提供一個簡潔明瞭的標題。
        • 提交 ID：輸入要 cherry-pick 的提交 ID。如果有多個提交，請用逗號分隔。
        • 類別：指定要求類別。
        • 審查員：如有多位審查員，請以半形逗號分隔 GitHub ID。
     3. 設定里程碑
        • 找到“里程碑”部分，然後點擊該設定。
        • 選擇合適的 XYZ 釋放阻擋器。此操作會觸發 cherry-pick 機器人處理您對「release-XYZ」分支的請求。
     4. 提交問題
        • 填妥所有詳細資料並設定里程碑後，即可提交問題。

   • 系統會處理要求，並通知您是否可挑選提交內容。如果提交是可 cherry-pick 的，這意味著在 cherry-pick 提交時不會發生合併衝突，那麼機器人將創建一個新的拉取請求。當拉取請求獲得 Bazel 團隊成員的批准後，提交將被 cherry-pick 並合併到發布分支。 有關已完成的 cherry-pick 請求的視覺範例，請參閱此 example。

5. 找出發布阻礙因素並修復發布分支上發現的問題。

   • 在 Bazel CI 中，發布分支會透過postsubmit和下游測試管道的相同測試套件進行測試。Bazel 團隊會監控發布分支的測試結果，並修正發現的任何回歸問題。

6. 解決所有已知的發布阻礙後，從發布分支建立新的候選版本。

   • 發布候選版本會在 bazel-discuss 上公告，Bazel 團隊會監控社群的候選版本錯誤報告。
   • 如果發現新的發布阻礙問題，請返回上一個步驟，並在解決所有問題後建立新的候選版本。
   • 在創建第一個發布候選版本之後，不允許向發布分支添加新功能；cherrypick 僅限於關鍵修復。如果需要進行選擇性更改，請求者必須回答以下問題：為什麼這項更改至關重要，它能帶來哪些好處？這種改變導致倒退的可能性有多大？

7. 如果沒有發現其他發布障礙，則將候選版本推送為正式版本。

   • 如果是修補程式版本，請在最後一個候選版本發布後，至少兩個工作天再推送版本。
   • 對於主要版本和次要版本，在最後一個候選版本發布後兩個工作天內發布正式版本，但不得早於第一個候選版本發布後一週。
   • 只有在隔天為工作天時，系統才會推送版本。
   • 新版本會在 bazel-discuss 上發布，Bazel 團隊會監控並處理社群提交的新版本錯誤報告。

回報迴歸問題

如果使用者在新的 Bazel 版本、候選版本甚至 Bazel HEAD 中發現回歸問題，請在 GitHub 上提交錯誤報告。您可以使用 Bazelisk 來定位導致問題的提交，並將此資訊包含在錯誤報告中。

例如，如果您的建置在 Bazel 6.1.0 下成功，但在 6.2.0 的第二個候選版本下失敗，您可以透過以下方式進行二分查找：

bazelisk --bisect=6.1.0..release-6.2.0rc2 build //foo:bar

您可以設定 BAZELISK_SHUTDOWN 或 BAZELISK_CLEAN 環境變數，執行對應的 bazel 指令來重設建構狀態，以便重現問題。詳情請參閱 Bazelisk bisect 功能的說明文件。

請記得將 Bazelisk 升級至最新版本，才能使用二分搜尋功能。

規則相容性

如果您是規則作者，且想維持與不同 Bazel 版本的相容性，請參閱「規則相容性」頁面。