Release
1.0.0
| 发布 | 地位 | 代号 | 初始版本 | 主动LTS开始 | 维护开始 | 寿命 |
|---|---|---|---|---|---|---|
| 18.x | 维护 | 氢 | 2022-04-19 | 2022-10-25 | 2023-10-18 | 2025-04-30 |
| 20.x | 维护 | 铁 | 2023-04-18 | 2023-10-24 | 2024-10-22 | 2026-04-30 |
| 22.x | LTS | 乔德 | 2024-04-24 | 2024-10-29 | 2025-10-21 | 2027-04-30 |
| 23.x | 当前的 | 2024-10-15 | - | 2025-04-01 | 2025-06-01 | |
| 24.x | 待办的 | 2025-04-22 | 2025-10-28 | 2026-10-20 | 2028-04-30 |
日期可能会发生变化。
发布时间表也可以作为JSON文件提供。
Node.js发布可以在：“当前”，“活跃的长期支持（LTS）”和“维护”中。奇数的释放线未升级为LTS-它们不会经过“活跃的LTS”或“维护”阶段。
nodejs/node主分支上的大多数非劳动（非破坏）变化。关键安全性和错误修复所需的更改可能会导致释放流中的Semver-Major变化降落，这种情况将很少见，并且会以Semver-Minor的身份降落。虽然，这些更改应该包含一个还原选项。
“受支持的发行线”一词将用于参考所有不是寿命终止的释放行。
| 发布 | 地位 | 代号 | 初始版本 | 主动LTS开始 | 维护LTS开始 | 寿命 |
|---|---|---|---|---|---|---|
| v0.10.x | 寿命 | - | 2013-03-11 | - | 2015-10-01 | 2016-10-31 |
| v0.12.x | 寿命 | - | 2015-02-06 | - | 2016-04-01 | 2016-12-31 |
| 4.x | 寿命 | 氩气 | 2015-09-08 | 2015-10-01 | 2017-04-01 | 2018-04-30 |
| 5.x | 寿命 | 2015-10-29 | - | 2016-06-30 | ||
| 6.x | 寿命 | 硼 | 2016-04-26 | 2016-10-18 | 2018-04-30 | 2019-04-30 |
| 7.x | 寿命 | 2016-10-25 | - | 2017-06-30 | ||
| 8.x | 寿命 | 碳 | 2017-05-30 | 2017-10-31 | 2019-01-01 | 2019-12-31 |
| 9.x | 寿命 | 2017-10-01 | - | 2018-06-30 | ||
| 10.x | 寿命 | dubnium | 2018-04-24 | 2018-10-30 | 2020-05-19 | 2021-04-30 |
| 11.x | 寿命 | 2018-10-23 | - | 2019-06-01 | ||
| 12.x | 寿命 | 铒 | 2019-04-23 | 2019-10-21 | 2020-11-30 | 2022-04-30 |
| 13.x | 寿命 | 2019-10-22 | - | 2020-06-01 | ||
| 14.x | 寿命 | 费尔米 | 2020-04-21 | 2020-10-27 | 2021-10-19 | 2023-04-30 |
| 15.x | 寿命 | 2020-10-20 | - | 2021-06-01 | ||
| 16.x | 寿命 | 镓 | 2021-04-20 | 2021-10-26 | 2022-10-18 | 2023-09-11 |
| 17.x | 寿命 | 2021-10-19 | - | 2022-06-01 | ||
| 19.x | 寿命 | 2022-10-18 | - | 2023-06-01 | ||
| 21.x | 寿命 | 2023-10-17 | - | 2024-04-01 | 2024-06-01 |
发布工作组的目的是：
它的责任是：
发布工作组成立为团队，工作组的会员资格不会自动导致这些团队的成员资格。这些团队是：
releasers团队委托秘密和CI访问能够构建和签名版本。在治理中概述的过程之后，必须由TSC批准释放团队的补充。
发布团队管理LTS版本的流程/内容以及这些版本所需的备份。发布团队的补充需要从发布团队的其余部分签名。
金矿（CITGM）团队中的金丝雀将Citgm保留为发行的主要理智检查之一。该团队维护CITGM存储库，并致力于保持Citgm的构建运行和定期通过。这还包括与建筑工作组合作维护CI工作。
New semver-major node.js的发行量每六个月从main分支。新的偶数版本将于4月发布，并于10月发行。
在与新的奇数主要版本的协调下，以前的偶数主要版本将过渡到长期支持。向长期支持的过渡将在Semver-Minor版本中发生，并且在新的主要版本发布后应该发生。
从进入LTS覆盖范围之日起，每个偶数（LTS）的主要版本将在12个月内积极维护。在这12个月的积极支持之后，主要版本将过渡为“维护”模式18个月。在Node.js 12之前，活动期为18个月，维护期为12个月。有关在每个释放阶段的预期更改将降落的详细信息，请参见释放阶段。
发布发布的确切日期将在LTS模式之间移至LTS，或者弃用的确切日期将不迟于每月更改的第一天。如果发布团队计划更改发布日期，则将在不少于14天的通知下完成。
所有LTS版本将分配一个代号。预期的即将到来的代号列表可在codenames.md中找到。
每个LTS主要版本都有GitHub存储库中的两个分支：一个释放分支和一个登台分支。发行分支用于切割新版本。只有 @nodejs/Releasers团队的成员才能致力于发布分支。登台分支用于从Main中挑选樱桃挑选或备份的委员会，这些提交需要包含在以后的版本中。 @nodejs/brockporter的成员只能进入分期分支。
例如，对于node.js v4，有一个v4.x分支和一个v4.x-staging分支。当Main的委托土地必须被樱桃挑选以获得未来的节点。JSV4发布时，必须将其降落到v4.x-staging分支中。当将提交用于将来的node.js v4版本时，必须以针对v4.x-staging分支的拉动请求的形式出现。当准备新的v4.x发布时，仅将提交降落在v4.x分支中。
通常，预计更改将在当前发行版中至少持续2周，然后再进行备份。可以由释放工作组酌情决定提早降落。
工作组成员是下面列出的发布者，备用者和CITGM团队成员的联盟。
