編寫版本資訊

回報問題 查看原始碼

本文的適用對象為 Bazel 貢獻者。

Bazel 中的修訂版本說明包括 RELNOTES: 標記,後面接著版本資訊。Bazel 團隊會使用這個欄位來追蹤每個版本的變更並撰寫版本公告。

總覽

  • 您做的變更是否有錯誤修正?在這種情況下,您不需要使用版本資訊。請提供 GitHub 問題參考資料。

  • 如果這項變更是以使用者可見的方式新增 / 移除 / 變更 Bazel,則提及變更會比較有利。

如果是重大變更,請先遵循設計文件政策

指南規範

使用者會閱讀版本資訊,因此其應該簡短 (最好是一句話),避免使用術語 (Bazel 內部術語),應著重在變更的內容。

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

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

  • 請勿只複製及貼上錯誤說明。它們通常很可怕,只能幫助我們跟上使用者版本資訊能夠以使用者容易理解的語言說明異動內容與原因。

  • 請一律使用時態,而「Bazel 現已支援 Y」或「X 現已支援 Z」。我們不希望版本資訊出現錯誤,例如:錯誤項目。所有版本資訊項目都必須具有參考價值,且使用一致的樣式和語言。

  • 如果已不適用或移除,請使用「X 已淘汰」或「X 已移除」。並非「已移除」或「已遭移除」。

  • 如果 Bazel 現在採取了不同的做法,請在目前時使用「X 現在是 $newBehavior,而不是 $oldBehavior」。如此一來,使用者就能進一步瞭解在使用新版本時會發生什麼情形。

  • 如果 Bazel 現在支援或不再支援某些功能,請使用「Bazel 現已支援/不再支援 X」。

  • 說明為何已移除 / 淘汰 / 變更任何項目。儘管這句話夠長,但我們希望使用者能夠評估對其建構的影響。

  • 「請勿」對日後的功能做出任何承諾。避免出現「這個標記會移除」或「系統將變更」。這會造成不確定性。使用者會想到的就是「時機?」,且不希望他們擔心自己目前的版本在不明時間中斷。

處理

發布流程中,我們收集每個修訂版本的 RELNOTES 標記。我們會在 Google 文件中複製所有內容,方便您審核、編輯和整理記事。

版本管理員會傳送電子郵件至 bazel-dev 郵寄清單。Bazel 貢獻者已受邀為文件貢獻一己之力,並確保公告內容能正確反映公告內容。

稍後,系統會使用 bazel-blog 存放區將公告提交至 Bazel 網誌