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