管理版本发布
版本发布是指项目正式发布新版本以便社区使用。版本发布有两种类型
- 常规版本发布遵循 语义化版本控制,并被视为可用于生产环境。
- 预发布版本不被视为可用于生产环境,旨在让社区预览即将发生的更改。
版本发布负责人
技术指导委员会 (TSC) 的一名成员被指定来管理每个计划的版本发布。版本发布负责人由发布前一天的 TSC 会议确定。
版本发布负责人负责
- 周五的计划版本发布
- 周末监控问题
- 确定周一是否需要发布补丁版本
- 发布补丁版本(如有必要)
版本发布负责人应在发布后的周一征求整个团队的意见,以再次检查是否需要发布补丁版本。
版本发布负责人需要访问 ESLint 的 npm 双因素身份验证才能进行版本发布。
版本发布沟通
每个计划的版本发布都与一个自动生成的版本发布问题相关联(示例)。版本发布问题是团队了解版本发布状态的信息来源,并包含版本发布负责人应遵循的清单。
流程
在计划的版本发布当天,版本发布负责人应遵循版本发布问题中的步骤。
所有与版本发布相关的沟通都发生在 Discord 的 #team
频道中的一个线程中。
在计划版本发布后的周一,版本发布负责人需要确定是否需要发布补丁版本。如果自计划版本发布以来发生以下任何情况,则需要发布补丁版本
- 回归错误导致人们的 lint 构建失败,而之前是通过的。
- 任何导致用户遇到大量问题的错误(通常是由于新功能导致)。
补丁版本发布的决定应在周一尽早做出。如果需要发布补丁版本,则遵循与计划版本发布流程相同的步骤。
在极少数情况下,如果已知版本存在严重的回归错误且尚未在周一修复,则可能需要发布第二个补丁版本。如果发生这种情况,版本发布负责人应在版本发布问题上宣布情况,并在所有补丁版本发布完成后再关闭问题。但是,通常最好将错误修复保留到下一个版本周期,而不是发布第二个补丁版本。
发布补丁版本后(或无需发布补丁版本),关闭版本发布问题并通知团队他们可以开始再次合并语义化版本次要变更。
版本发布参数
下表显示了在 Jenkins 上启动 eslint-js Release
(@eslint/js
包版本)和 eslint Release
(eslint
包版本)作业以使用最新功能发布新版本时,作为 RELEASE_TYPE
选择的选项示例。在这两个作业中,应选择 main
作为 RELEASE_BRANCH
。
HEAD 版本 | 期望的下一个版本 | eslint-js Release RELEASE_TYPE |
---|---|---|
9.25.0 |
9.25.1 |
patch |
9.25.0 |
9.26.0 |
minor |
9.25.0 |
10.0.0-alpha.0 |
alpha.0 |
10.0.0-alpha.0 |
10.0.0-alpha.1 |
alpha |
10.0.0-alpha.1 |
10.0.0-beta.0 |
beta |
10.0.0-beta.0 |
10.0.0-beta.1 |
beta |
10.0.0-beta.1 |
10.0.0-rc.0 |
rc |
10.0.0-rc.0 |
10.0.0-rc.1 |
rc |
10.0.0-rc.1 |
10.0.0 |
major |
HEAD 版本 | 期望的下一个版本 | eslint Release RELEASE_TYPE |
---|---|---|
9.25.0 |
9.25.1 或 9.26.0 |
latest |
9.25.0 |
10.0.0-alpha.0 |
alpha |
10.0.0-alpha.0 |
10.0.0-alpha.1 |
alpha |
10.0.0-alpha.1 |
10.0.0-beta.0 |
beta |
10.0.0-beta.0 |
10.0.0-beta.1 |
beta |
10.0.0-beta.1 |
10.0.0-rc.0 |
rc |
10.0.0-rc.0 |
10.0.0-rc.1 |
rc |
10.0.0-rc.1 |
10.0.0 |
latest |
发布先前主要版本的最新版本时,作为 RELEASE_TYPE
选择的选项取决于 HEAD 版本是否为预发布版本。在这两个作业中,应选择相应的开发分支(例如,v9.x-dev
)作为 RELEASE_BRANCH
。
HEAD 版本 | 先前主要版本 | 期望的下一个版本 | eslint-js Release RELEASE_TYPE |
---|---|---|---|
10.0.0-alpha.0 |
9.25.0 |
9.25.1 |
patch |
10.0.0-alpha.0 |
9.25.0 |
9.26.0 |
minor |
10.0.0 |
9.25.0 |
9.25.1 |
maintenance.patch |
10.0.0 |
9.25.0 |
9.26.0 |
maintenance.minor |
HEAD 版本 | 先前主要版本 | 期望的下一个版本 | eslint Release RELEASE_TYPE |
---|---|---|---|
10.0.0-alpha.0 |
9.25.0 |
9.25.1 或 9.26.0 |
latest |
10.0.0 |
9.25.0 |
9.25.1 或 9.26.0 |
maintenance |
紧急版本发布
紧急版本发布是计划外的,不是定期计划的版本发布或预期的补丁版本发布。
一般来说,我们尽量避免紧急版本发布。即使存在回归错误,最好也等到周一再看看是否出现其他问题,以便补丁版本发布可以修复尽可能多的问题。
唯一的例外情况是,如果 ESLint 对大多数当前用户完全不可用。例如,我们曾经推送过一个版本,由于缺少一些核心文件,导致每个人都出错。在这种情况下,紧急版本发布是合适的。
故障排除
npm publish
返回 404
这通常是由于与 npm 令牌相关的权限错误导致的。
release-please
使用一年后过期的细粒度访问令牌。此令牌与eslintbot
npm 帐户绑定,需要每年 3 月重新生成。如果访问令牌已过期,则npm publish
返回 404。- Jenkins 使用没有过期日期的经典访问令牌,但确实需要 2FA 代码才能发布。如果 2FA 代码不正确,则
npm publish
返回 404。