“发布管理员（Release Managers）” 是一个总称，通过使用 SIG Release 提供的工具， 负责维护发布分支、标记发行版本以及创建发行版本的贡献者。
每个角色的职责如下所述。
| 邮件列表 | Slack | 可见范围 | 用法 | 会员资格 |
|---|---|---|---|---|
| release-managers@kubernetes.io | #release-management（频道）/@release-managers（用户组） | 公共 | 发布管理员公开讨论 | 所有发布管理员（包括助理和 SIG 主席） |
| release-managers-private@kubernetes.io | 不适用 | 私人 | 拥有特权的发布管理员私人讨论 | 发布管理员，SIG Release 负责人 |
| security-release-team@kubernetes.io | #security-release-team（频道）/@security-rel-team（用户组） | 私人 | 与安全响应委员会协调安全发布 | security-discuss-private@kubernetes.io, release-managers-private@kubernetes.io |
发布的相关信息受到禁运，我们已经定义了有关如何设置这些禁运的政策。 更多信息请参考安全禁运政策。
注意：补丁发布团队和分支管理员手册以后将会删除重复数据。
注意： 文档可能涉及补丁发布团队和分支管理角色。这两个角色被合并到发布管理员角色中。
发布管理员和发布管理员助理的最低要求是：
git 和 git 相关命令行触发的分支源代码工作流。发布管理员负责：
x.y.z，其中 z > 0）x.y.z，其中 z = 0）该团队有时与安全响应委员会密切合作，因此应遵守安全发布流程中规定的指导方针。
GitHub 访问控制：@kubernetes/release-managers
GitHub 提及：@kubernetes/release-engineering
要成为发布管理员，须先担任发布管理员助理。助理通过在多个周期内积极处理发布，从而毕业成为发布管理员，并且：
发布管理员助理是发布管理员的学徒，以前称为发布管理员影子。他们负责：
GitHub 提及：@kubernetes/release-engineering
贡献者可以通过展示以下内容成为助理：
SIG Release 主席和技术负责人负责：
之所以此处明确提及他们，是因为他们是每个角色的各种沟通渠道和权限组（GitHub 团队、GCP 访问）的所有者。 因此，他们是享有很高特权的社区成员，并参与了一些私人沟通，这些沟通有时可能与 Kubernetes 安全披露有关。
GitHub 团队：@kubernetes/sig-release-leads
有关以往的分支管理员，可以在 release-x.y/release_team.md
中 kubernetes/sig-release 仓库的发布目录中找到。
例如：1.15 发布团队