本文档面向 Bazel 贡献者。
Bazel 中的提交说明包含一个 RELNOTES: 标记，后跟版本说明。Bazel 团队使用此参数来跟踪每个版本的更改并撰写版本公告。
概览
您的更改是否能够修复 bug？在这种情况下，您不需要发布版本说明。请提供对 GitHub 问题的引用。
如果更改以用户可见的方式添加 / 移除 / 更改 Bazel，那么提及它或许是有利的。
如果变更重大，请先遵循设计文档政策。
准则
版本说明将由我们的用户阅读，因此版本说明应简洁明了（最好是一句话），应避免使用行话（Bazel 内部术语），应重点说明变更内容。
添加指向相关文档的链接。几乎所有版本说明都应该包含链接如果说明中提到了标志、功能、命令名称，那么用户可能会想要详细了解相关内容。
在代码、符号、标志或任何包含下划线的字词前后使用反引号。
不要只是复制和粘贴错误描述。这类游戏通常含糊不清 只对我们来说有意义，会让用户抓挠版本说明旨在以用户能理解的语言说明更改内容以及更改原因。
始终使用现在时态和格式“Bazel 现在支持 Y”或“X 现在执行 Z”。我们不希望版本说明听起来像是 bug 条目。所有版本说明条目都应详实，并采用一致的风格和语言。
如果某些内容已弃用或移除，请使用“X 已废弃”或“X 已移除”。而非“已移除”或“已移除”。
如果 Bazel 现在采取了不同的做法，请使用“X now $newBehavior 而非 $oldBehavior”形式。这样一来，用户就会详细地了解使用新版本时会发生什么。
如果 Bazel 现在支持或不再支持某些内容，请使用“Bazel 现在支持/不再支持 X”。
说明移除 / 弃用 / 更改的原因。一句话就足够了，但我们希望用户能够评估对其 build 的影响。
请勿对未来推出的功能做出任何承诺。避免“此标志将被移除”或“这将进行更改”。这会带来不确定性。用户首先会想知道的是“何时？”，我们不希望用户开始担心他们当前的 build 在某个未知时间会中断。
处理
在发布流程中，我们会收集每次提交的 RELNOTES 标记。我们会将所有内容复制到 Google 文档中，然后在文档中查看、修改和整理笔记。
发布管理员向 bazel-dev 邮寄名单发送电子邮件。我们邀请 Bazel 贡献者为文档提供内容，并确保其更改正确反映在公告中。
之后，系统会使用 bazel-blog 代码库将公告提交到 Bazel 博客。