このドキュメントは、Bazel のコントリビューターを対象としています。
Bazel のコミットの説明には、RELNOTES: タグとリリースノートが含まれています。これは、各リリースの変更を追跡し、リリース アナウンスを作成するために Bazel チームによって使用されます。
概要
変更がバグ修正である場合、リリースノートは必要ありません。GitHub の問題への参照を含めてください。
変更によって Bazel がユーザーにわかる形で追加、削除、変更される場合は、言及することをおすすめします。
変更が重要な場合は、まず設計ドキュメント ポリシーに従ってください。
ガイドライン
リリースノートはユーザーが読むものなので、短く（理想的には 1 文）、専門用語（Bazel 内部の用語）を避け、変更の内容に焦点を当てる必要があります。
関連ドキュメントへのリンクを含めます。ほとんどのリリースノートにはリンクを含める必要があります。説明でフラグ、機能、コマンド名に言及している場合は、ユーザーが詳細を知りたいと思う可能性があります。
コード、記号、フラグ、またはアンダースコアを含む単語はバッククォートで囲みます。
バグの説明をそのままコピーして貼り付けないでください。多くの場合、説明はわかりにくく、私たちにしか理解できず、ユーザーは困惑してしまいます。リリースノートは、何が変更されたのか、その理由をユーザーが理解できる言葉で説明するためのものです。
常に現在形を使用し、「Bazel now supports Y」または「X now does Z」の形式を使用します。 リリースノートがバグのエントリのように聞こえないようにします。すべてのリリースノートのエントリは、有益で、一貫したスタイルと言語を使用する必要があります。
非推奨または削除されたものがある場合は、「X has been deprecated」または「X has been removed」を使用します。 「is removed」または「was removed」ではありません。
Bazel の動作が変更された場合は、現在形で「X now $newBehavior instead of $oldBehavior」を使用します。これにより、新しいリリースを使用する際に何が期待できるかをユーザーに詳しく知らせることができます。
Bazel が何かをサポートするようになった場合、またはサポートしなくなった場合は、「Bazel now supports / no longer supports X」を使用します。
削除、非推奨、変更された理由を説明します。1 文で十分ですが、ユーザーがビルドへの影響を評価できるようにする必要があります。
将来の機能について約束しないでください。「このフラグは削除されます」や「これは変更されます」は避けてください。 不確実性が生じます。ユーザーが最初に疑問に思うのは「いつ？」であり、現在のビルドがいつか不明なタイミングで壊れることを心配させたくありません。
プロセス
リリース プロセスの一環として、すべてのコミットの RELNOTES タグを収集します。すべてを Google
ドキュメント
にコピーし、そこでノートを確認、編集、整理します。
リリース マネージャーは、 bazel-dev メーリング リストにメールを送信します。 Bazel のコントリビューターは、ドキュメントに貢献し、変更がアナウンスに正しく反映されるようにします。
後で、bazel-blog repositoryを使用して、お知らせがBazel blogに投稿されます。