版本管理
发布是指项目向社区正式发布新版本，有两种类型的发布：
- 遵循语义化版本的常规发布，可以直接投入生产。
- 预发布，不适合直接投入生产环境，以便社区预览即将到来的变化。
发布管理者
技术指导委员会（TSC）的一名成员被指定来管理每个预定的发布。发布管理者是在发布前一天的 TSC 会议上确定的。
发布管理者负责：
- 在周五预定发布
- 在周末监测议题
- 确定是否有必要在周一发布补丁
- 发布补丁版本（如果需要）
发布管理者应该在发布后的周一征求整个团队的意见，以反复检查是否有必要发布补丁。
发布管理者需要有权访问 ESLint 的 npm 双因素认证，以便进行发布。
发布沟通
每个预定的发布都应该与发布议题相关联（例子）。发布议题是团队关于发布状态的信息来源。要确保发布议题有“发布（release）”的标签，以便于找到它。
过程
在预定发布的当天，发布管理者应遵循以下步骤：
- 审查开放的拉取请求，看是否有应该被合并的。一般来说，你可以合并以下拉取请求：
- 已经开放了至少两天并且已获批准的拉取请求（这些请求只是在等待合并）。
- 重要的拉取请求（由团队决定）。如果没有应该在合并前暂停并让人们审查。
- 文档修改
- 由团队成员发出的小型错误修复。
- 登录 Jenkins 安排“ESLint Release”构建工作。
- 在 Jenkins 上观察构建的控制台输出。有时候构建会暂停并输出链接，其中需要输入六位数 2FA 代码。
- 从你的认证器应用中输入当前的六位数 2FA 代码。
- 继续构建并等待完成。
- 在“亮点（Highlights）”部分更新博客发布文章，包括新规则和其他任何重要内容。
- 在公共聊天室中公开发布公告。
- 在 Twitter 上公开发布公告。
- 在发布议题上公开发布公告。记录发布过程中出现的任何议题，并提醒团队不要合并除文档修改和错误修复以外的任何东西，保持发布议题的开放。
- 在发布议题上添加“待发布补丁（patch release pending）”的标签（当存在此标签是
eslint-github-bot会对非语义化版本补丁的拉取请求进行待定状态检查，以确保它们不会在补丁发布待定时被合并）。
所有与发布相关的沟通都在 Discord 的 #team 频道中进行。
在预定发布后的周一，发布管理者需要确定是否有必要发布补丁。如果在计划发布后发生了以下情况，则认为有必要发布补丁：
- 回归缺陷导致人们的检查构建失败，在此之前没有问题。
- 任何有用户大量反馈的漏洞（经常是新功能导致的）。
应该尽可能早地在周一决定是否发布补丁。如果有必要发布补丁，那么就按照预定发布程序的相同步骤进行。
在极少数情况下，如果已知该版本有严重的回归，并且在周一之前没有被修复，那么可能需要进行第二次补丁发布。如果发生这种情况，发布管理者应该在发布议题上宣布这一情况，并在所有补丁发布完成之前保留这一议题。不过，通常情况下，为下一个发布周期修复漏洞比做第二个补丁发布要好。
在发布了补丁版本后（或者没有必要发布补丁版本），关闭发布议题，并通知团队可以再次开始合并次版本修改。
紧急发布
紧急发布是指不在预期中、不得不进行的补丁发布。
一般情况下，我们尽量不进行紧急发布。即使有回归，最好也要等到周一，看看是否有其他议题出现，这样补丁发布才能尽可能多地修复问题。
当大多数用户反馈此 ESLint 版本完全无法使用才适合进行紧急发布。就像我们曾经推送过一个版本，因为它缺少一些核心文件，导致每个人没法正常使用。