このドキュメントは、Bazel のコントリビューターを対象としています。
Bazel での commit の説明では、RELNOTES: タグの後にリリースノートを記述します。Bazel チームは、これを使用して各リリースの変更を追跡し、リリースのお知らせを作成します。
概要
変更はバグの修正ですか？このような場合、リリースノートは必要ありません。GitHub の問題への参照を記載してください。
この変更によってユーザーが認識できる方法で Bazel が追加 / 削除 / 変更される場合は、そのように言及することが有利である可能性があります。
変更が大きい場合は、まず設計ドキュメント ポリシーに従ってください。
ガイドライン
リリースノートはユーザーが読むため、短いもの（1 文が理想的）とし、専門用語（Bazel 内部の用語）は使用せず、変更の内容に焦点を当ててください。
関連ドキュメントへのリンクを含めます。ほとんどのリリースノートには、リンクが含まれています。説明にフラグ、機能、コマンド名などが含まれていれば、ユーザーは詳しい情報を知りたいと思うでしょう。
コード、記号、フラグ、またはアンダースコアを含む単語は、バッククォートで囲みます。
バグの説明をコピーして貼り付けることはしないでください。多くの場合、暗号のようなもので、私たちには理解しかね、ユーザーが頭を傷つけるおそれがあります。リリースノートは、変更点とその理由をユーザーが理解しやすい言葉で説明するためのものです。
常に現在形と、「Bazel now supports Y」または「X now does Z」の形式を使用してください。Google では、リリースノートをバグのエントリのように見せたくないためです。リリースノートのすべてのエントリは、参考になる内容で、スタイルと言語に一貫性を持たせる必要があります。
非推奨または削除された機能がある場合は、「X のサポートが終了しました」または「X が削除されました」を使用します。「削除された」や「削除された」ではない。
Bazel の処理方法が異なる場合は、現在形で「$oldBehavior ではなく $newBehavior を X に」を使用してください。これにより、ユーザーは新しいリリースを使用した場合に想定されることを詳細に把握できます。
Bazel ですでに X がサポートされるようになったか、サポートされなくなった場合は、「Bazel で X がサポートされるようになった / サポートが終了した」という説明です。
削除 / 非推奨 / 変更が行われた理由を説明してください。1 文で十分ですが、ビルドに対する影響をユーザーが評価できるようにする必要があります。
将来の機能について確約しないでください。「このフラグは削除される」や「今後変更される」という表現は使用しないでください。不確実性をもたらします。ユーザーが真っ先に疑問に思うのは「いつか」です。知らないうちに、現在のビルドが壊れることを心配しなくて済むようにする必要があります。
プロセス
リリース プロセスの一環として、Google はすべての commit の RELNOTES タグを収集します。すべてを Google ドキュメントにコピーして、メモを確認、編集、整理します。
リリース マネージャーは、bazel-dev メーリング リストにメールを送信します。Bazel のコントリビューターは、このドキュメントのコントリビューターを招待して、変更内容がお知らせに正しく反映されるようにすることができます。
このお知らせは、bazel-blog リポジトリを使用して Bazel ブログに送信されます。