本文档面向 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 博客。