本文档面向 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 文档中，并在其中查看、修改和整理记事。
发布管理员向 bazel-dev 邮寄名单发送电子邮件。我们邀请 Bazel 贡献者贡献文档，并确保他们的更改在公告中正确体现。
稍后，通知将使用 bazel-blog 代码库提交到 Bazel 博客。