為因應您的需求，Bazel 持續發展，因此我們想分享 2025 年的發展藍圖更新。
我們預計在 2025 年底推出 Bazel 9.0 長期支援 (LTS) 版本。
全面改用 Bzlmod
自 Bazel 7 起，Bzlmod 已成為 Bazel 的標準外部依附元件系統，取代舊版 WORKSPACE 系統。截至 2025 年 3 月，Bazel Central Registry 已託管超過 650 個模組。
在 Bazel 9 中，我們將完全移除 WORKSPACE 功能，而 Bzlmod 將成為在 Bazel 中導入外部依附元件的唯一方式。為盡量降低社群的遷移成本，我們將著重於進一步改善遷移指南和工具。
此外，我們也打算實作改良的共用存放區快取 (請參閱 #12227)，並進行垃圾收集，可能也會將其反向移植到 Bazel 8。Bazel Central Registry 也會支援驗證 SLSA 認證。
遷移 Android、C++、Java、Python 和 Proto 規則
在 Bazel 8 中，我們已將 Android、Java、Python 和 Proto 規則的支援功能，從 Bazel 程式碼集遷移至對應存放區中的 Starlark 規則。為簡化遷移作業，我們在 Bazel 中實作了自動載入功能，可透過 --incompatible_autoload_externally 和 --incompatible_disable_autoloads_in_main_repo 標記控制。
在 Bazel 9 中，我們預計預設停用自動載入功能，並要求每個專案在 BUILD 檔案中明確載入必要規則。
我們將大部分的 C++ 語言支援功能重新編寫為 Starlark，從 Bazel 二進位檔中分離出來，並移至 /rules_cc 存放區。這是 Bazel 仍支援的最後一個主要語言。
我們也將 C++、Java 和 Proto 規則的單元測試移植到 Starlark，並將這些規則移至實作項目旁邊的存放區，以加快規則作者的速度。
Starlark 改善項目
Bazel 將可延遲評估符號巨集。也就是說，如果系統未要求巨集宣告的目標，就不會執行符號巨集，進而提升大型套件的效能。
Starlark 將採用實驗性型別系統，類似於 Python 的型別註解。我們預期在 Bazel 9 發布後，型別系統就會趨於穩定。
可設定性
我們的重點是減少建構標記的成本和混淆情況。
我們正在測試新的專案設定模型，使用者不必知道要在何處設定哪些建構和測試標記。因此 $ bazel test //foo 會根據 foo 專案的政策，自動設定正確的旗標。這項功能在 9.0 版中可能仍為實驗功能，歡迎提供引導式意見回饋。
旗標範圍可讓您在 Starlark 旗標離開專案界線時將其移除，以免這些旗標破壞不需要這些旗標的遞移依附元件快取。這可降低使用轉場效果的建構成本，並加快建構速度。以下為範例。我們正在擴展這個概念，以控管要將哪些標記傳播至執行設定，並考慮提供更彈性的支援，例如使用自訂 Starlark 判斷哪些依附元件邊緣應傳播標記。
我們正優先處理這項工作，將內建語言標記從 Bazel 移至 Starlark，以便與相關規則定義共存。
遠端執行作業改善項目
我們計畫新增非同步執行作業的支援功能，藉此提高平行處理能力，加快遠端執行速度。
如要追蹤藍圖的最新動態及討論預定功能，請加入 slack.bazel.build 的社群 Slack 伺服器。
這份藍圖旨在向社群說明團隊對 Bazel 9.0 的意圖。優先順序可能會根據開發人員和客戶意見回饋，或新的市場商機而有所變動。