このドキュメントは、Bazel コントリビューターを対象としています。
Bazel の commit の説明には、RELNOTES: タグの後にリリースが続きます
あります。これは、Bazel チームが各リリースの変更を追跡し、リリースのお知らせを作成するために使用されます。
概要
変更内容はバグ修正ですか？その場合は、リリースノートは必要ありません。GitHub の問題への参照を含めてください。
変更によって Bazel がユーザーに表示される形で追加、削除、変更される場合は、そのことを記載することをおすすめします。
大幅な変更の場合は、設計ドキュメントに従う ポリシーをご確認ください。
ガイドライン
リリースノートを読むのはユーザーであるため、短く（理想的には 1 文）、専門用語（Bazel 内部用語）を避け、変更内容に焦点を当てるようにしてください。
関連するドキュメントへのリンクを記載します。ほとんどのリリースノートで、 リンクを含めます。説明にフラグ、機能、コマンド名が記載されている場合は、ユーザーは詳細を知りたいと考えています。
コード、記号、フラグ、または 使用します。
バグの説明をコピーして貼り付けないでください。多くの場合、わかりにくいものであり、Google にしか意味がなく、ユーザーは困惑します。リリースノートは 変更点とその理由をユーザーにとって理解しやすい言葉で説明することを目的とします。
常に現在形を使用し、「Bazel が Y をサポートするようになりました」または「X が Z をサポートするようになりました」という形式を使用します。リリースノートがバグエントリのような印象を与えるのは避けたいと考えています。リリースノートのエントリはすべて、有益な情報を提供し、一貫したスタイルと言語を使用する必要があります。
非推奨または削除があった場合は、「X は非推奨です」という表現を使用します。または「X」 削除されました。」「削除」されない「削除されました」などと表示されるので、
Bazel の動作が変更された場合は、「X は $oldBehavior ではなく $newBehavior になりました」という現在時制を使用します。これにより、ユーザーは新しいリリースを使用する際に何が期待できるかを詳しく知ることができます。
Bazel でサポートが開始された機能やサポートが終了した機能については、「Bazel で X のサポートが開始 / 終了しました」を使用します。
削除、サポート終了、変更の理由を説明します。1 文を ビルドへの影響をユーザーが評価できるようにする必要があります。
今後の機能について確約しないでください。「このフラグは削除されます」や「これは変更されます」などの表現は避けてください。不確実性が生まれます。まず、 ユーザーは「いつ？」と疑問に思うでしょう。セキュリティに関する懸念を 現在のビルドがいつの間にか壊れてしまったのです。
プロセス
リリース プロセスの一環として、すべての commit の RELNOTES タグを収集します。すべてを Google ドキュメントにコピーし、メモを確認、編集、整理します。
リリース マネージャーは bazel-dev メーリング リストにメールを送信します。Bazel のコントリビューターは、ドキュメントに貢献し、変更が通知に正しく反映されるようにすることができます。
その後、お知らせは Bazel ブログ、bazel-blog リポジトリをご覧ください。