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團隊成員的聯盟。
