如原始網誌文章所述,Bazel 4.0 及以上版本支援兩種測試群組:滾動式版本和長期支援 (LTS) 版本。本頁面說明 Bazel 發布模型的最新資訊。
支援矩陣
LTS 版本 | 支援階段 | 最新版本 | 支援終止 |
---|---|---|---|
Bazel 8 | 累計 | 查看「滾動式版本」頁面 | 不適用 |
Bazel 7 | 運作中 | 7.1.1 | 2026 年 12 月 |
Bazel 6 | 維護 | 6.5.0 | 2025 年 12 月 |
Bazel 5 | 維護 | 5.4.1 | 2025 年 1 月 |
Bazel 4 | 已淘汰 | 4.2.4 | 2024 年 1 月 |
所有 Bazel LTS 版本都可以在 GitHub 的版本頁面中找到。
發布版本
Bazel 會使用 major.minor.patch 語意版本管理配置。
- 主要版本包含與先前版本不回溯相容的功能。每個主要 Bazel 版本都是 LTS 版本。
- 次要版本包含回溯相容的錯誤修正和從主要分支版本移植的功能。
- 修補程式版本包含重大錯誤修正。
此外,在下一個主要版本號碼中,加上連字號和日期後置字串,即可表示預先發布版。
舉例來說,如果您針對每種類型推出新版本,那麼版本號碼如下:
- 主要:6.0.0
- 次要:6.1.0
- 修補程式:6.1.2
- 預先發布版:7.0.0-pre.20230502.1
支援階段
每個主要的 Bazel 版本都有四個支援階段:
- Rolling:這個主要版本仍在預先發布階段,Bazel 團隊會從 HEAD 發布滾動式版本。
- 使用中:這個主要版本是目前有效的 LTS 版本。Bazel 團隊會將重要功能和錯誤修正項目向後移植至次要版本。
- 維護:這個主要版本是維護模式下的舊版 LTS 版本。Bazel 團隊保證只會將安全性問題和 OS 相容性問題的重要錯誤修正向後移植到這個 LTS 版本。
- 已淘汰:Bazel 團隊不再提供這個主要版本的支援,所有使用者應改用較新的 Bazel LTS 版本。
發布頻率
Bazel 會定期為兩個測試群組發布版本。
滾動式版本
- 滾動式版本與 Google Blaze 版本協調,並每兩週從 HEAD 發布。這是下一個 Bazel LTS 的預覽版本。
- 推出版本可能會發布不相容的變更。建議針對主要的破壞性變更,使用不相容的標記;推出不相容的變更時,請遵循我們的回溯相容性政策。
LTS 版本
- 主要版本:我們預計每隔 12 個月就會從 HEAD 版本剪輯較新的 LTS 版本。新的 LTS 版本發布後,會立即進入 Active 階段,而先前的 LTS 版本則會進入維護階段。
- 次要版本:Active LTS 測試群組新的小版本預計會每 2 個月推出一次。
- 修補程式版本:對於「使用中」和「維護」階段的 LTS 版本,我們預計會隨需求推出新的修補程式版本,進行重大錯誤修正。
- Bazel LTS 版本進入「維護」階段 2 年後,就會進入「已淘汰」階段。
如要瞭解預定版本,請查看 GitHub 上的版本問題。
發布程序與政策
滾動式版本的程序相當簡單:大約每兩週就會建立新版本,與 Google 內部 Blaze 版本保持一致。由於發布時程快速,我們不會向後移植任何滾動式版本變更。
如為 LTS 版本,請遵循下列程序和政策:
- 決定版本的基準修訂版本。
- 對於新的主要 LTS 版本,基準修訂版本是主要分支版本的 HEAD。
- 如果是次要版本或修補程式版本,基準修訂版本是相同 LTS 版本目前最新版本的標頭。
- 從基準修訂版本的
release-<version>
名稱中建立發布分支版本。 - 透過 PR 將變更向後移植至發布分支版本。
- 社群可以建議要向後移植某些修訂版本,方法是針對相關 GitHub 問題或 PR 回覆「
@bazel-io flag
」,將這些項目標示為潛在發布攔截器,Bazel 團隊會將這些修訂版本分類,並決定是否要將修訂版本向後移植。 - 只有主要分支版本上的回溯相容修訂版本可以向後移植,而需要進行其他小幅變更來解決合併衝突。
- 社群可以建議要向後移植某些修訂版本,方法是針對相關 GitHub 問題或 PR 回覆「
使用 Cherry-Pick 要求問題向 Bazel 維護人員向後移植變更。
Bazel 維護人員可以要求將特定修訂版本匯出至發布分支版本。這項程序的第一步是在 GitHub 建立 cherry 挑選要求。做法如下。
- 開啟cherry-Pick 要求
- 填寫要求詳細資料
- 標題:為要求提供簡明扼要的標題。
- 修訂版本 ID:輸入要挑選的修訂版本 ID。如果您有多個修訂版本,請以半形逗號分隔。
- 類別:指定要求的類別。
- 審查者:如果有多個審查人員,請以半形逗號分隔他們的 GitHub ID。
- 設定里程碑
- 找到「里程碑」部分並按一下設定。
- 選取適當的 X.Y.Z 發布攔截器。這個動作會觸發 cherry 挑選的機器人,以處理您對「release-X.Y.Z」分支版本的要求。
- 提交問題
- 填妥所有詳細資料並設定 miestone 後,請提交問題。
cherry 挑選的機器人會處理要求,並通知修訂版本是否有資格進行 Cherry 挑選。如果修訂版本可佈建,也就是說在收購修訂版本時不會產生合併衝突,機器人就會建立新的提取要求。當 Bazel 團隊的成員核准提取要求時,系統會精心挑選修訂版本,並將修訂版本合併至發布分支版本。如需完整 cherry 挑選要求的視覺範例,請參閱這個範例。
找出發布版本阻礙,並修正系統在版本分支中發現的問題。
- 在 Bazel CI 上的 postsubmit 和下游測試管道中,使用相同的測試套件來測試發布分支版本。Bazel 團隊會監控發布分支版本的測試結果,並修正任何發現的迴歸問題。
解決所有已知的發布區塊後,從發布分支版本建立新的候選版本。
- 我們也會在 bazel-discuss 上公布這個候選版本,Bazel 團隊會監控該候選項目的社群錯誤報告。
- 如果發現新的發布攔截器,請返回最後步驟,解決所有問題後,建立新的候選版。
- 建立第一個候選版本後,就無法將新功能新增至發布分支版本。
如果找不到任何發布封鎖工具,則將候選發布版本推送為官方版本
- 如果是修補程式版本,請至少在上一個候選版本推出後至少兩個工作天推送版本。
- 針對主要和次要版本,請在最後一個候選版發布的兩個工作天後推送發布,但不得早於第一個候選版本發布後一週。
- 系統只會在隔天為工作天發布版本。
- 這個版本會在 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 升級至最新版本,以便使用 Binct 功能。
規則相容性
如果您是規則作者,並想維持與不同 Bazel 版本的相容性,請查看規則相容性頁面。