发布后通信

Kubernetes *版本沟通*团队（属于SIG Release）负责版本公告，这些公告会发布在主项目博客上。

每次发布后，版本沟通团队会接管主博客一段时间，并发布一系列额外的文章来解释或公告与该版本相关的更改。这些额外的文章被称为*版本后沟通*。

选择加入版本后沟通

在发布周期中，作为贡献者，您可以选择就即将发布的 Kubernetes 更改进行版本后沟通。

要选择加入，您需要针对k/website仓库打开一个草稿、*占位符*拉取请求（PR）。最初，这可以是一个空的提交。在您的占位符 PR 的描述中提及 KEP 问题或其他 Kubernetes 改进问题。

当您打开*草稿*拉取请求时，请针对 `main` 分支作为基础分支打开，而不是针对 `dev-1.35` 分支。这与发布前更改和新功能的流程不同。

您还应该在相关的kubernetes/enhancements问题上留下评论，并附上 PR 的链接，以通知负责此次发布的版本沟通团队。您的评论有助于团队了解该更改需要公告，并且您的 SIG 已选择加入。

除了以上内容，您最好通过 Slack（频道`#release-comms`）联系版本沟通团队，告知他们您已完成此操作并希望选择加入。

准备文章内容

您应遵循通常的文章提交流程，将您的占位符 PR 转换为可供审查的内容。但是，对于版本后沟通，您可能没有*写作伙伴*；取而代之的是，版本沟通团队可能会指派一名团队成员来帮助指导您的工作。

您应该压缩（squash）您的拉取请求中的提交；如果您不确定如何操作，完全可以向版本沟通团队或博客团队寻求帮助。

前提是您的文章在前端设置（front matter）中被标记为草稿（`draft: true`），PR 可以在发布周期中的任何时间合并。

发布

在实际发布之前，版本沟通团队会检查哪些内容已准备就绪（如果在截止日期前未准备好，且未获得豁免，则公告将不包含在内）。他们会为将要发布的文章制定时间表，并打开新的拉取请求，将这些文章从草稿状态变为已发布。

博客团队的批准者仍然会对内容从草稿到接受发布的推广提供最终批准。在发布日期之前，用于发布这些公告的 PR（或 PR 组）应具有 LGTM（“看起来不错”）和已批准标签，以及*do-not-merge/hold*标签，以确保 PR 不会被过早合并。

版本沟通团队/版本团队随后可以在网站 Git 仓库解冻后（发布实际发生后）立即*取消暂挂*该 PR（或 PR 组）。

在每篇文章计划发布的当天，自动化会触发一次网站构建，该文章就会变得可见。