撰寫版本資訊

回報問題 查看原始碼 Nightly · 8.0 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

本文件適用於 Bazel 貢獻者。

Bazel 中的修訂版本說明包含 RELNOTES: 標記,後面接著是版本附註。Bazel 團隊會使用這項資訊,追蹤每個版本的變更內容,並撰寫版本發布公告。

總覽

  • 您的變更是否為錯誤修正?在這種情況下,您不需要發布版本說明。請附上 GitHub 問題的參照資料。

  • 如果變更會以使用者可見的方式新增 / 移除 / 變更 Bazel,則提及這項變更可能會有所助益。

如果變更幅度相當大,請先遵循設計文件政策

指南規範

我們的使用者會閱讀發布說明,因此請簡短扼要 (最好是用一句話表達),避免使用專業術語 (Bazel 內部術語),並著重於變更內容。

  • 請附上相關說明文件的連結。幾乎所有版本說明都應包含連結。如果說明提到標記、功能或指令名稱,使用者可能會想進一步瞭解。

  • 在程式碼、符號、標記或任何含有底線的字詞前後加上倒引號。

  • 請勿只複製及貼上錯誤說明。這些訊息通常很難解讀,只有我們才能理解,使用者會因此感到困惑。版本說明旨在以使用者能理解的語言,說明變更內容和變更原因。

  • 請一律使用現在式,並使用「Bazel 現已支援 Y」或「X 現已執行 Z」的格式。我們不希望版本資訊聽起來像是錯誤項目。所有版本附註項目都應提供實用資訊,並使用一致的樣式和語言。

  • 如果某項功能已淘汰或移除,請使用「X 已淘汰」或「X 已移除」。不要使用「is removed」或「was removed」

  • 如果 Bazel 現在做了一些不同的事情,請使用現在式「X now $newBehavior instead of $oldBehavior」。這可讓使用者詳細瞭解使用新版本時的預期結果。

  • 如果 Bazel 目前支援或不再支援某項功能,請使用「Bazel 目前支援/不再支援 X」的格式。

  • 說明為何移除 / 淘汰 / 變更某些內容。一句話就夠了,但我們希望使用者能夠評估對其版本的影響。

  • 請勿對日後的功能做出任何承諾。請避免使用「這個旗標將會移除」或「這會有所變更」等字眼。這會導致不確定性。使用者首先會想知道「何時?」,我們不希望他們開始擔心目前的版本會在某個未知的時間發生問題。

程序

發布程序中,我們會收集每個版本的 RELNOTES 標記。我們會將所有內容複製到 Google 文件中,以便查看、編輯及整理筆記。

發布管理員會傳送電子郵件給 bazel-dev 郵寄清單。我們邀請 Bazel 的開發人員協助編輯這份文件,並確保他們的變更內容正確反映在公告中。

稍後,我們會使用 bazel-blog 存放區,將這項公告提交至 Bazel 網誌