本文档面向 Bazel 贡献者。
Bazel 中的提交说明包含 RELNOTES: 标记，后跟版本说明。Bazel 团队会使用此信息来跟踪每个版本中的更改并撰写版本公告。
概览
您的更改是 bug 修复吗？在这种情况下，您无需提供版本说明。请添加 GitHub 问题的引用。
如果更改以用户可见的方式添加 / 移除 / 更改了 Bazel，则最好提及这一点。
如果更改较大，请先遵循设计文档政策。
指南
用户会阅读版本说明，因此说明应简短（最好是一条句子），避免使用专业术语（Bazel 内部术语），应重点说明相关变更。
请附上相关文档的链接。几乎所有版本说明都应包含链接。如果说明中提及了标志、功能或命令名称，用户可能希望详细了解这些内容。
对代码、符号、标志或包含下划线的任何字词使用反引号。
请勿仅复制和粘贴 bug 说明。它们通常很难懂，只有我们能理解，而用户会感到困惑。版本说明旨在用用户能够理解的语言说明具体变化及原因。
请始终使用现在时，格式为“Bazel 现在支持 Y”或“X 现在支持 Z”。我们不希望版本说明看起来像 bug 条目。所有版本说明条目都应具有信息性，并使用一致的样式和语言。
如果某项内容已废弃或已移除，请使用“X 已废弃”或“X 已移除”。而非“已移除”或“已移除”。
如果 Bazel 现在执行了不同的操作，请使用现在时态的“X now $newBehavior instead of $oldBehavior”。这样，用户就可以详细了解使用新版本时会遇到什么情况。
如果 Bazel 现在支持或不再支持某项功能，请使用“Bazel 现在支持/不再支持 X”。
说明某项内容被移除 / 弃用 / 更改的原因。一句话就足够了，但我们希望用户能够评估对其 build 的影响。
请勿就未来的功能做出任何承诺。避免使用“此标志将被移除”或“此项将发生更改”等字样。这会引入不确定性。用户首先会想知道“何时”，而我们不希望他们开始担心当前 build 会在某个未知的时间崩溃。
流程
在发布流程中，我们会收集每个提交的 RELNOTES 标记。我们会将所有内容复制到 Google 文档中，在其中检查、修改和整理记事。
发布经理向 bazel-dev 邮寄名单发送电子邮件。我们诚邀 Bazel 贡献者为本文档做出贡献，并确保其所做的更改正确反映在公告中。
之后，我们会使用 bazel-blog 代码库将公告提交到 Bazel 博客。