版本发布后沟通

Kubernetes 的 发布沟通 (Release Comms) 团队 (隶属于 SIG Release) 负责发布公告，这些公告会发布在 主项目博客上。

每次发布后，发布沟通团队会在一段时间内接管主博客，并发布一系列额外的文章来解释或宣布与该发布相关的变更。这些额外的文章被称为 发布后沟通 (post-release comms)。

选择参与发布后沟通

在一个发布周期内，作为贡献者，你可以选择参与关于 Kubernetes 即将到来的变更的发布后沟通。

要选择参与，你需要针对 k/website 开启一个草稿（draft）、占位符 (placeholder) 拉取请求 (PR)。最初，这可以是一个空的提交。在占位符 PR 的描述中提及 KEP issue 或其他 Kubernetes 改进 issue。

当你开启草稿拉取请求时，你的基础分支应是 main，而不是 dev-1.34 分支。这与针对即将发布的变更和新功能的流程不同。

你还应该在相关的 kubernetes/enhancements issue 上留言，提供 PR 链接，以通知管理此发布的发布沟通团队。你的评论有助于团队了解到该变更需要宣布，并且你的 SIG 已选择参与。

除了上述步骤，理想情况下，你应该通过 Slack (频道 #release-comms) 联系发布沟通团队，告知他们你已完成这些步骤并希望参与。

准备文章内容

你应该遵循常规的文章提交流程，将你的占位符 PR 转换为可供评审的内容。然而，对于发布后沟通，你可能没有一个 撰写伙伴 (writing buddy)；此时，发布沟通团队可能会指派一名成员来指导你完成工作。

你应该压缩 (squash) 你拉取请求中的提交；如果你不确定如何操作，完全可以向发布沟通团队或博客团队寻求帮助。

只要你的文章在前置元数据 (front matter) 中被标记为草稿（draft: true），该 PR 可以在发布周期的任何时间合并。

发布

在正式发布之前，发布沟通团队会检查哪些内容已准备就绪（如果到截止日期还未准备好，并且你没有获得例外，那么该公告将不会被包含）。他们会为即将发布的文章制定发布计划，并开启新的拉取请求，将这些文章从草稿状态转为已发布状态。

博客团队的 approver 仍然会对将内容从草稿提升到可接受发布状态提供最终批准。在发布日之前，用于发布这些公告的 PR（或多个 PR）应带有 LGTM (“looks good to me”) 和 approved 标签，同时加上 do-not-merge/hold 标签，以确保 PR 不会过早合并。

一旦版本正式发布后，网站 Git 仓库解除冻结，发布沟通团队或发布团队便可以 解除搁置 (unhold) 该 PR（或多个 PR）。

在每篇文章预定发布的日期，自动化流程会触发网站构建，该文章便会变得可见。