このドキュメントは、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-blog リポジトリを使用して、Bazel ブログに通知が送信されます。