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