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