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