版本模型

如原始網誌文章所述，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 軌的新次要版本。
• 修補程式版本：如果需要修正重大錯誤，預計會視需求發布新修補程式版本，適用於處於「Active」和「Maintenance」階段的 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 Request Issue，為 Bazel 維護人員回溯變更。

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

     1. 開啟挑選要求
     2. 填寫要求詳細資料
        • 標題：為要求提供簡潔的說明標題。
        • 提交 ID：輸入要挑選的提交 ID。如果有多個提交，請以半形逗號分隔。
        • 類別：指定要求類別。
        • 審查員：如有數名審查員，請以半形逗號分隔 GitHub ID。
     3. 設定里程碑
        • 找到「里程碑」部分，然後按一下設定。
        • 選取適當的 X.Y.Z 版本發布阻礙因素。這項動作會觸發 Cherry-pick 機器人，處理「release-X.Y.Z」分支的要求。
     4. 提交問題
        • 填妥所有詳細資料並設定里程碑後，即可提交問題。

   • 系統會處理要求，並通知您提交是否符合挑選條件。如果可以挑選提交內容 (也就是挑選提交內容時沒有合併衝突)，機器人就會建立新的提取要求。當 Bazel 團隊成員核准提取要求後，系統會挑選並合併提交至發布分支。如要查看完成的挑選要求範例，請參閱這個範例。

5. 找出發布阻礙並修正發布分支中的問題。

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

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

   • 候選版本會在 bazel-discuss 上發布，Bazel 團隊會監控社群針對候選版本提出的錯誤報告。
   • 如果發現新的發布阻礙問題，請返回上一個步驟，並在解決所有問題後建立新的候選版本。
   • 建立第一個候選版本後，就不得在發布分支中新增功能；只能挑選重要修正。如果需要挑選，要求者必須回答下列問題：這項變更為何至關重要？可帶來哪些好處？這項變更是否可能導致回歸？

7. 如果沒有其他發布阻礙，請將候選版本推送為正式版本

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

回報迴歸問題

如果使用者在新版 Bazel、候選版本，甚至是 HEAD 的 Bazel 中發現回歸，請在 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 升級至最新版本，才能使用 bisect 功能。

規則相容性

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