本文適用於 Bazel 貢獻者。
Bazel 中的提交說明包含 RELNOTES: 標記，後方為版本說明。Bazel 團隊會使用這項資訊追蹤每個版本的變更，並撰寫發布公告。
總覽
您的變更是否為修正錯誤？在這種情況下，您不需要發行說明。請附上 GitHub 問題的參考資料。
如果變更會以使用者可見的方式新增 / 移除 / 變更 Bazel，則可能適合提及。
如果變更幅度很大，請先遵循設計文件政策。
指南規範
使用者會閱讀版本說明，因此請簡短說明 (最好只有一句話)，避免使用術語 (Bazel 內部用語)，並著重於變更內容。
附上相關說明文件的連結。幾乎所有版本說明都應包含連結。如果說明中提到旗標、功能或指令名稱，使用者可能會想進一步瞭解。
在程式碼、符號、旗標或任何含有底線的字詞前後加上反引號。
請勿只是複製及貼上錯誤說明。這些訊息通常很難理解，只有我們看得懂，使用者則會感到困惑。發行說明應以使用者看得懂的語言，說明變更內容和原因。
一律使用現在式，並採用「Bazel 現在支援 Y」或「X 現在會 Z」格式。我們不希望版本資訊聽起來像是錯誤記錄。所有版本說明項目都應提供實用資訊，並使用一致的樣式和語言。
如果某個項目已淘汰或移除，請使用「X 已淘汰」或「X 已移除」。請勿使用「已移除」或「已移除」。
如果 Bazel 現在的做法不同，請使用現在式，例如「X now $newBehavior instead of $oldBehavior」。讓使用者詳細瞭解新版本的功能。
如果 Bazel 現在支援或不再支援某項功能，請使用「Bazel 現在支援/不再支援 X」。
說明某個項目遭到移除 / 淘汰 / 變更的原因。一句話就夠了，但我們希望使用者能夠評估對建構作業的影響。
請勿對日後的功能做出任何承諾。避免使用「這個旗標將會移除」或「這項設定將會變更」。這會帶來不確定性。使用者首先會想知道「何時」會發生這種情況，我們不希望他們開始擔心目前的建構作業會在某個未知時間中斷。
程序
在發布程序中，我們會收集每個提交的 RELNOTES 標記。我們會將所有內容複製到 Google 文件，然後在該處查看、編輯及整理記事。
發布管理員會傳送電子郵件給 bazel-dev 郵寄清單。我們邀請 Bazel 貢獻者參與文件編輯，確保公告正確反映他們的變更。
稍後，公告會使用 bazel-blog 存放區提交至 Bazel 網誌。