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