为发布版本记录功能
每个 Kubernetes 主要版本都会引入需要文档记录的新功能。新版本还会带来对现有功能和文档的更新（例如将功能从 Alpha 升级到 Beta）。
通常，负责某个功能的 SIG 会将该功能的文档草案作为拉取请求提交到 kubernetes/website 存储库的相应开发分支，SIG Docs 团队中的某个人会提供编辑反馈或直接编辑草案。本节介绍了两个小组在发布版本期间使用的分支约定和流程。
面向文档贡献者
通常，文档贡献者不会为发布版本从头开始编写内容。相反，他们会与创建新功能的 SIG 合作，完善文档草案并使其准备好发布。
选择要记录或协助的功能后，请在 #sig-docs Slack 频道、SIG Docs 每周会议上或直接在功能 SIG 提交的 PR 上询问。如果获得批准，您可以使用提交到他人的 PR中描述的技术之一编辑 PR。
了解即将推出的功能
要了解即将推出的功能，请参加 SIG Release 每周会议（有关即将召开的会议，请参阅社区页面）并关注kubernetes/sig-release 存储库中特定于发布版本的文档。每个版本在/sig-release/tree/master/releases/ 目录中都有一个子目录。该子目录包含发布计划、发布说明草案以及列出发布团队中每个人的文档。
发布计划包含指向与发布版本相关的所有其他文档、会议、会议纪要和里程碑的链接。它还包含有关发布目标和时间表的信息，以及为此版本制定的任何特殊流程。在文档底部附近，定义了几个与发布版本相关的术语。
此文档还包含指向**功能跟踪表**的链接，这是了解计划纳入发布版本的所有新功能的官方途径。
发布团队文档列出了负责每个发布角色的人员。如果不清楚应该与谁讨论您遇到的特定功能或问题，请参加发布会议提出您的问题，或联系发布负责人，以便他们为您指明方向。
发布说明草案是了解有关发布版本的特定功能、变更、弃用以及更多信息的理想场所。内容要到发布周期后期才会最终确定，因此请谨慎使用。
功能跟踪表
给定 Kubernetes 版本的功能跟踪表列出了计划用于发布版本的每个功能。每个项目包括功能名称、指向功能主要 GitHub 问题的链接、其稳定性级别（Alpha、Beta 或 Stable）、负责其实现的 SIG 和个人、是否需要文档、功能的发布说明草案以及是否已合并。请记住以下几点
- Beta 和 Stable 功能通常比 Alpha 功能具有更高的文档优先级。
- 很难测试（因此也很难记录）尚未合并或至少在其 PR 中被视为功能完整的功能。
- 确定功能是否需要文档是一个手动过程。即使某个功能未标记为需要文档，您也可能需要记录该功能。
面向开发人员或其他 SIG 成员
本节面向为发布版本记录新功能的其他 Kubernetes SIG 成员。
如果您是为 Kubernetes 开发新功能的 SIG 成员，则需要与 SIG Docs 合作，以确保您的功能在发布版本之前得到记录。查看功能跟踪电子表格或在 #sig-release Kubernetes Slack 频道中查看，以验证计划详细信息和截止日期。
打开占位符 PR
- 在
kubernetes/website存储库中针对dev-1.31分支打开一个**草案**拉取请求，并进行一个小的提交，稍后您将对其进行修改。要创建草案拉取请求，请使用“创建拉取请求”下拉菜单并选择**创建草案拉取请求**，然后单击**草案拉取请求**。 - 编辑拉取请求描述以包含指向kubernetes/kubernetes PR 和kubernetes/enhancements 问题的链接。
- 在相关的kubernetes/enhancements 问题上留下包含 PR 链接的评论，以通知管理此版本的文档负责人功能文档即将发布，应跟踪发布。
如果您的功能不需要任何文档更改，请务必通过在 #sig-release Slack 频道中提及来告知 sig-release 团队。如果该功能确实需要文档但未创建 PR，则该功能可能会从里程碑中移除。
PR 已准备好进行审查
准备好后，使用功能文档填充占位符 PR，并将 PR 的状态从草案更改为**准备好进行审查**。要将拉取请求标记为准备好进行审查，请导航到合并框并单击**准备好进行审查**。
尽力描述您的功能及其使用方法。如果您在构建文档方面需要帮助，请在 #sig-docs Slack 频道中询问。
完成内容后，分配给您功能的文档负责人将对其进行审查。为了确保技术准确性，内容可能还需要来自相应 SIG 的技术审查。使用他们的建议使内容达到发布就绪状态。
如果您的功能需要文档但未收到第一份草案内容，则该功能可能会从里程碑中移除。
功能门控
如果您的功能是 Alpha 或 Beta 功能并且受功能门控保护，则需要在 content/en/docs/reference/command-line-tools-reference/feature-gates/ 中为其创建一个功能门控文件。文件名应为功能门控，从 UpperCamelCase 转换为 kebab-case，后缀为 .md。您可以查看同一目录中已有的其他文件，以了解您的文件应该是什么样子。通常，一段就足够了；对于较长的解释，请在其他地方添加文档并链接到该文档。
此外，为了确保您的功能门控出现在Alpha/Beta 功能门控表中，请在 Markdown 描述文件的frontmatter中包含以下详细信息
stages:
- stage: <alpha/beta/stable/deprecated> # Specify the development stage of the feature gate
defaultValue: <true or false> # Set to true if enabled by default, false otherwise
fromVersion: <Version> # Version from which the feature gate is available
toVersion: <Version> # (Optional) The version until which the feature gate is available
对于全新的功能门控，还需要单独描述该功能门控；在 content/en/docs/reference/command-line-tools-reference/feature-gates/ 中创建一个新的 Markdown 文件（使用其他文件作为模板）。
将功能门控从默认禁用更改为默认启用时，您可能还需要更改其他文档（而不仅仅是功能门控列表）。请注意以下措辞，例如“exampleSetting 字段是一个 Beta 字段，默认情况下处于禁用状态。您可以通过启用 ProcessExampleThings 功能门控来启用它。”
如果您的功能已 GA 或已弃用，请在描述文件的 stages 块中包含一个额外的 stage 条目。确保 Alpha 和 Beta 阶段保持不变。此步骤会将功能门控从Alpha/Beta 功能门控表转换到已毕业或已弃用功能门控表。例如
stages:
- stage: alpha
defaultValue: false
fromVersion: "1.12"
toVersion: "1.12"
- stage: beta
defaultValue: true
fromVersion: "1.13"
toVersion: "1.18"
# Added 'stable' stage block to existing stages.
- stage: stable
defaultValue: true
fromVersion: "1.19"
toVersion: "1.27" 最终，Kubernetes 将完全停止包含该功能门控。要表示移除功能门控，请在相应描述文件的 frontmatter 中包含 removed: true。此操作会触发将功能门控从已毕业或已弃用功能门控部分转换到名为功能门控（已移除）的专用页面，包括其描述。
所有 PR 均已审查并准备好合并
如果您的 PR 在发布截止日期之前尚未合并到 dev-1.31 分支，请与管理发布版本的文档负责人合作，以便在截止日期之前将其合并。如果您的功能需要文档但文档尚未准备好，则该功能可能会从里程碑中移除。