版本发布

用户 > 版本发布描述了我们的自动发布流程。通常情况下，每周发布不需要我们进行任何维护工作。

但是，我们偶尔会进行两种类型的发布，这两种发布都需要手动操作。

主要版本发布

根据用户 > 版本 > 主要版本，我们很少发布包含累积性重大变更的主要版本。

1. 预发布准备

创建一个名为发布版本的里程碑 [示例：里程碑 6.0.0]。
如果针对推荐规则配置更改的问题尚不存在，请创建一个 [示例：针对 5.0.0 的 recommended 集的更改]。
将打算用于该版本的任何重大更改添加到该里程碑。
搜索源代码注释（不包括 CHANGELOG.md 文件），这些注释提到了已弃用的代码和/或新主要版本的待办事项，并在该里程碑中创建相应的问题。
- 例如，对于新的主要版本 8，搜索可能包括
  - /deprecated|todo/i
  - /v8/i
  - /todo.*v?8/i
创建一个问题以提高依赖项的最低版本 [示例：增强功能：提高 v8 的依赖项的最低版本]
在项目存储库（不是个人 fork）中从 main 分支创建两个新分支
- v${major}
- v${major}-canary-auto-release
从 v${major}-canary-auto-release 分支向 main 分支提交一个 PR，修改 ci.yml 工作流和 README.md [示例：chore: 为 v6 添加自动金丝雀发布]
- ci.yml:
  - 在文件开头的 push: > branches: 下，添加一个 - v${major} 列表项。
  - 添加一个 publish_canary_version_v${major} 步骤，与 publish_canary_version 相同，除了
    - 将 if 条件的分支检查更改为：if: github.ref == 'refs/heads/v${major}'。
    - 其发布命令应为 npx nx release publish --tag rc-v${major} --verbose。
- README.md:
  - 添加指向 Netlify 上为该分支创建的 v${major}--typescript-eslint.netlify.app 预览部署环境的链接。
- 在审查后将其合并到 main 中，并重新设置 v${major} 分支的基础。

1a. 共享配置更改

主版本是我们唯一真正有机会更改稳定版 `recommended*` 和 `stylistic*` 配置中的值的机会。与主版本的一般 PR 流程平行

在 typescript-eslint Discord 上创建一个 `v${major}` 频道
创建一个讨论，其中包含一个表格，总结所有提议的规则更改 [示例：6.0.0 配置更改]
将该讨论发布到 typescript-eslint Discord 和社交媒体上
一旦 (1 个月) 和 (讨论平息) 中较长的时间过去，请在 `v${major}` 分支上创建一个问题并发送一个相应的 PR，进行相应的更改 [示例：Configs: 将更改应用于 v6 的配置预设]

1b. 自愿社区测试

与共享配置更改工作并行，确保在愿意尝试的流行社区项目上测试 beta 版本。

创建一个固定问题，为消费者提供尝试新版本 beta 的机会 [示例：在各种有影响力的社区仓库上尝试 v8 beta]
- 询问每个社区项目是否愿意尝试新版本，例如在他们的 Discord 或问题跟踪器上。
- 每个表示愿意接收 PR 的社区项目都应该有一个 PR。
一旦提议的 *共享配置更改* 合并到 `v${major}` 分支，请向每个项目发送一个包含新 beta 版本的草稿 PR。

1c. 社区测试后配置调整

作为社区测试的一部分，可能会发现对预设配置的额外更改。如果是这样

创建一个讨论，描述建议的更改 [示例：Configs: v6 配置的最后一轮“最终”更改]
将此新讨论发布到之前的配置更改讨论中，在 typescript-eslint Discord 上，以及在社交媒体上。
一旦 (2 周) 和 (讨论平息) 中较长的时间过去

如果可能，我们希望避免进行第二轮配置更改。这些更改应该只针对在社区测试中反复出现的问题。

2. 合并重大变更

从 v${major} 分支向 main 分支发送一个 PR [示例：v6.0.0].
将所有重大变更 PR 设置为指向 v${major} 分支。
- 为了表明这些更改是重大的，PR 描述的第一行必须以 BREAKING CHANGE: 开头，第二行应简要概述更改内容。
- 需要注意的是，合并后提交信息也必须包含 BREAKING CHANGE: 作为第一行，以便 nx release 在发布说明中将其识别为重大变更。如果漏掉了这一行，就意味着在编写发布文档时需要进行更多的手动工作。
编写并发布一篇博客文章，宣布新的 beta 版本 [示例：Docs: Blog post describing changes & migration strategy for v5->v6].
- 随着更改在 v${major} 分支中落地，请保持这篇博文更新。
等待所有必要的 PR 合并。
编写一篇博客文章，宣布新版本发布 [示例：Docs: Release blog post for v6], 并将其发布到 v${major} 分支。
让发布等待 **至少 1 周**，以便早期采用者有时间帮助测试并讨论更改。
- 在 @tseslint 推特上进行推广，以获得更多关注。
一旦讨论尘埃落定，通过暂时为仓库启用该合并设置，将 PR 传统合并到 main 分支上。

注意

非重大变更可以合并到 main 分支或主要分支。它们不需要任何特殊处理。

3. 发布版本

与维护人员讨论，准备好进行非计划发布。手动执行此操作有助于确保有人在场，以处理重大版本发布可能出现的任何问题。
准备发布说明。nx release 将自动在 GitHub 上生成发布说明，但这些说明将杂乱无章，对用户没有帮助。我们需要重新组织发布说明，将重大变更放在最前面，使其最显眼。如果需要任何迁移，我们必须列出步骤，以便用户可以轻松地进行迁移。
- 发布说明示例：v6.0.0，v5.0.0
最后，在 @tseslint 的推特上发布新版本，并附上 GitHub 发布链接。确保你包含了关于新版本亮点的额外信息！

非计划发布

根据用户 > 发布 > 非计划发布，我们可能会手动触发新的发布，以应对罕见的紧急情况，例如严重回归。如果发生这种情况

在任何相关的 issue 中提及你打算发布非计划版本
在私人的维护 Discord 频道中发布你正在进行此操作的消息
发送一个解决 issue 的 pull request
等待最多一天（视情况而定）以获得批准，然后再合并 PR
触发私有发布工作流程以导致新的发布
在相同的 issue 中发布新发布版本(s) 的链接

主要版本发布​

1. 预发布准备​

1a. 共享配置更改​

1b. 自愿社区测试​

1c. 社区测试后配置调整​

2. 合并重大变更​

3. 发布版本​

非计划发布​