Node.js 发布节奏演进深度解读从一年双版本到年度单版本与 Alpha 通道【免费下载链接】nodejs.orgThe Node.js® Website项目地址: https://gitcode.com/GitHub_Trending/no/nodejs.org本篇文章以 Node.js 官方公告《Evolving the Node.js Release Schedule》为骨架系统解读从 2026 年 10 月起生效的新版发布计划每年仅发布一个主版本、每个版本最终都会成为 LTS并新增 Alpha 通道用于早期破坏性变更测试。读完本文你将完整理解新旧计划的时间线差异、Alpha 通道与 Nightly 构建的本质区别以及该计划在 nodejs.org 官网源码中的落地方式从而为自己的升级策略和 CI 兼容性测试做出更准确的规划。变化总览TL;DR新计划的核心结论可以浓缩为三句话如果你只升级到 LTS 版本除了版本号之外几乎感觉不到变化——LTS 支持窗口依旧相近而现在每一个发布版本最终都会成为 LTS从 27.x 开始Node.js 将由每年两个主版本变为每年一个主版本库作者请务必尽早把 Alpha 版本集成到自己的 CI 中——如果你只在 LTS 版本上测试就无法在破坏性变更波及用户之前向项目反馈问题。为什么会有这次改变现行发布计划已经运行了 10 年。它诞生于 io.js 合并时期目的是平衡当时快速增长生态的需求正如当时一位贡献者所言它本质上是对企业需求的一次有根据的猜测an educated guess of what enterprises would need。如今项目已经积累了整整十年的真实使用数据这些数据清晰地指向几个结论奇数版本采用率极低绝大多数用户会直接等待 Long-Term SupportLTS版本奇偶版本区分让新手感到困惑许多组织完全跳过奇数版本只升级到 LTS。与此同时企业需要的是可预测性。新计划的设计目标正是well-defined——让团队可以据此规划升级窗口、合理分配资源。志愿者可持续性Node.js 主要由志愿者维护。虽然部分贡献者获得了赞助但绝大多数工作——评审 Pull Request、处理安全问题、发布版本、回移植修复——都是由维护者在业余时间完成的。同时维护四到五条活跃发布线让安全发布的管理变得难以持续每增加一条发布线回移植backporting的复杂度都会随之上升。通过减少并发发布线数量项目可以把精力集中到用户真正在用的版本上提供更好的支持。从 2026 年 10 月起将发生什么变化每年只发布一个主版本4 月发布 Current10 月晋升 LTS每个版本都会成为 LTS——不再有奇偶之分Node.js 27 也将成为 LTS新增 Alpha 通道用于早期测试允许包含 semver-major破坏性变更Alpha 版本号遵循 semver 预发布格式例如27.0.0-alpha.1版本号与首次 Current 发布所在日历年对齐27.0.0 在 2027 年发布28.0.0 在 2028 年发布以此类推显著减轻 Releasers发布者的工作负担。新日程表阶段时长说明Alpha6 个月10 月至次年 3 月。早期测试允许 semver-major 变更Current6 个月4 月至 10 月。稳定性巩固期LTS30 个月长期支持提供安全修复EOL无限期项目不再提供任何支持从首次 Current 发布到 End of Life (EOL)总支持周期为 36 个月。关于 Alpha 通道Alpha 通道填补了昔日奇数版本承担的早期测试角色但有一个关键区别Alpha 阶段允许 semver-major破坏性变更。Alpha 发布是经过签名signed、打标签tagged并通过 CITGM 测试的。CITGMCanary in the Goldmine金矿中的金丝雀是 Node.js 维护的工具它会在即将发布的新版本 Node.js 上运行主流开源软件包的测试套件从而在发布前尽早发现生态兼容性问题并通知相关软件包作者。与 Nightly 构建的区别这与 Nightly 构建 不同。Nightly 是直接从main分支自动生成的、未经测试的构建而Alpha 发布不一定包含main上的全部变更。一个变更可能不会被包含进某个 Alpha 版本可能的原因是在 Pull Request 评审期间评审者添加了要求不将本变更回移植的标签例如某个 API 在 Alpha 版本中被运行时弃用runtime deprecated那么真正移除该 API 的变更应当等到下一条发布线再落地在 Alpha 发布准备阶段发布者最终决定哪些提交进入该版本例如某个依赖更新引入了严重缺陷。目标人群与预期面向谁库作者以及需要测试与新破坏性变更兼容性的 CI 流水线。不应用于生产环境。可以预期什么发布经过签名和打标签这与 Nightly 不同API 可能在版本之间发生变化发布节奏是灵活的——Release Team 将根据变更数量和项目需求决定 Alpha 发布的时间和频率。为什么这样做提供了 Nightly 构建所缺乏的质量门槛下的破坏性变更早期反馈同时允许 V8 更新在周期中更早落地。关于哪些 semver-major 提交可以在 Alpha 版本中发布的规则将由 Release Team 定义并记录在 Release 仓库 中。不会改变的内容LTS 支持时长保持相近30 个月迁移窗口被保留LTS 版本之间仍然存在重叠期质量标准不变——相同的测试、相同的 CITGM、相同的安全流程日程依旧可预测——4 月发布10 月 LTS 晋升V8 采用周期不变——Node.js 最新版本仍将包含最多约 6 个月以内的 V8 版本。时间线Node.js 26 时间表现有模式里程碑日期26.0.02026 年 4 月进入 LTS2026 年 10 月进入 Maintenance2027 年 10 月End of Life2029 年 4 月Node.js 26 遵循现有计划这是旧模型下的最后一条发布线。Node.js 27 时间表新模型里程碑日期Alpha 开始2026 年 10 月27.0.02027 年 4 月进入 LTS2027 年 10 月End of Life2030 年 4 月Node.js 27 是新计划下的第一条发布线。未来 10 年版本AlphaCurrentLTSEnd of Life27.x2026 年 10 月2027 年 4 月2027 年 10 月2030 年 4 月28.x2027 年 10 月2028 年 4 月2028 年 10 月2031 年 4 月29.x2028 年 10 月2029 年 4 月2029 年 10 月2032 年 4 月30.x2029 年 10 月2030 年 4 月2030 年 10 月2033 年 4 月31.x2030 年 10 月2031 年 4 月2031 年 10 月2034 年 4 月32.x2031 年 10 月2032 年 4 月2032 年 10 月2035 年 4 月33.x2032 年 10 月2033 年 4 月2033 年 10 月2036 年 4 月34.x2033 年 10 月2034 年 4 月2034 年 10 月2037 年 4 月35.x2034 年 10 月2035 年 4 月2035 年 10 月2038 年 4 月36.x2035 年 10 月2036 年 4 月2036 年 10 月2039 年 4 月需要注意该计划并非最终定稿仍可能被修订。关于项目对各版本支持声明的权威、实时记录请参阅 nodejs/Release 仓库中的schedule.json。新模型在 nodejs.org 官网中的落地新发布计划不仅是项目层面的决策也已经反映在 nodejs.org 网站的源码与页面中可以作为理解该计划的补充佐证状态分类的数据来源releaseData.mjs 中的getNodeReleaseStatus根据 EOL 日期和 LTS 标志把每个主版本归入EOL、LTS或Current三类状态——这正是新模型中每个版本都走向 LTS这一表述在官网上的直接体现majorNodeReleases.mjs 则通过 nodevu 过滤出有明确支持声明即出现在schedule.json中的主版本类型定义types/releases.ts 中的NodeReleaseStatus LTS | Current | EOL定义了站内版本状态的取值范围用户可见的说明previous-releases.mdx 明确写道历史上截至 Node.js 26奇数版本在六个月后停止支持、偶数版本进入 Active LTS自 Node.js 27 起改为年度周期每个主版本在六个月的 Current 阶段外加六个月的 Alpha 阶段之后都会进入 LTSLTS 通常保证 30 个月的关键缺陷修复并建议生产应用只使用 Active LTS 或 Maintenance LTS状态徽章渲染PreviousReleasesTable/TableBody.tsx 使用STATUS_KIND_MAP把每个版本的status映射为对应样式的 Badge让用户在各版本一览表中直接看到 LTS / Current / EOL 状态EOL 的定义eol.mdx 说明了版本进入 EOL 后不再获得任何更新包括安全补丁并列出不升级的代价漏洞无法修复、工具链断裂、生态漂移、合规风险下载页引用current.mdx 在下载页中引导用户前往发布计划页面了解 release schedule 与 LTS 状态。对用户与库作者的建议普通用户 / 只使用 LTS 的团队新计划对你几乎没有影响。只需按新日历每年 4 月新 Current、10 月新 LTS安排升级即可且每个新版本最终都会成为 LTS选择空间反而更大库作者把每个新版本的 Alpha 通道尽早接入 CI。正如公告强调的——如果你只在 LTS 上测试就无法在破坏性变更影响你的用户之前上报问题企业规划者新计划的well-defined特性让跨版本升级窗口LTS 重叠期可以提前数年排定建议按本文未来 10 年表格提前规划升级与资源投入。结语这一变革源于 GitHub issue、Release Working Group 会议以及 2025 年 Chesapeake Collaboration Summit 上的持续讨论并将在伦敦的 Collaboration Summit 上继续深入。项目感谢所有贡献反馈的参与者如果你有任何问题或意见可以在 nodejs/Release 仓库的 issue #1113 中继续讨论。对于希望了解官方实时支持声明的人schedule.json始终是最权威的参考。【免费下载链接】nodejs.orgThe Node.js® Website项目地址: https://gitcode.com/GitHub_Trending/no/nodejs.org创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Node.js 发布节奏演进深度解读从一年双版本到年度单版本与 Alpha 通道【免费下载链接】nodejs.orgThe Node.js® Website项目地址: https://gitcode.com/GitHub_Trending/no/nodejs.org本篇文章以 Node.js 官方公告《Evolving the Node.js Release Schedule》为骨架系统解读从 2026 年 10 月起生效的新版发布计划每年仅发布一个主版本、每个版本最终都会成为 LTS并新增 Alpha 通道用于早期破坏性变更测试。读完本文你将完整理解新旧计划的时间线差异、Alpha 通道与 Nightly 构建的本质区别以及该计划在 nodejs.org 官网源码中的落地方式从而为自己的升级策略和 CI 兼容性测试做出更准确的规划。变化总览TL;DR新计划的核心结论可以浓缩为三句话如果你只升级到 LTS 版本除了版本号之外几乎感觉不到变化——LTS 支持窗口依旧相近而现在每一个发布版本最终都会成为 LTS从 27.x 开始Node.js 将由每年两个主版本变为每年一个主版本库作者请务必尽早把 Alpha 版本集成到自己的 CI 中——如果你只在 LTS 版本上测试就无法在破坏性变更波及用户之前向项目反馈问题。为什么会有这次改变现行发布计划已经运行了 10 年。它诞生于 io.js 合并时期目的是平衡当时快速增长生态的需求正如当时一位贡献者所言它本质上是对企业需求的一次有根据的猜测an educated guess of what enterprises would need。如今项目已经积累了整整十年的真实使用数据这些数据清晰地指向几个结论奇数版本采用率极低绝大多数用户会直接等待 Long-Term SupportLTS版本奇偶版本区分让新手感到困惑许多组织完全跳过奇数版本只升级到 LTS。与此同时企业需要的是可预测性。新计划的设计目标正是well-defined——让团队可以据此规划升级窗口、合理分配资源。志愿者可持续性Node.js 主要由志愿者维护。虽然部分贡献者获得了赞助但绝大多数工作——评审 Pull Request、处理安全问题、发布版本、回移植修复——都是由维护者在业余时间完成的。同时维护四到五条活跃发布线让安全发布的管理变得难以持续每增加一条发布线回移植backporting的复杂度都会随之上升。通过减少并发发布线数量项目可以把精力集中到用户真正在用的版本上提供更好的支持。从 2026 年 10 月起将发生什么变化每年只发布一个主版本4 月发布 Current10 月晋升 LTS每个版本都会成为 LTS——不再有奇偶之分Node.js 27 也将成为 LTS新增 Alpha 通道用于早期测试允许包含 semver-major破坏性变更Alpha 版本号遵循 semver 预发布格式例如27.0.0-alpha.1版本号与首次 Current 发布所在日历年对齐27.0.0 在 2027 年发布28.0.0 在 2028 年发布以此类推显著减轻 Releasers发布者的工作负担。新日程表阶段时长说明Alpha6 个月10 月至次年 3 月。早期测试允许 semver-major 变更Current6 个月4 月至 10 月。稳定性巩固期LTS30 个月长期支持提供安全修复EOL无限期项目不再提供任何支持从首次 Current 发布到 End of Life (EOL)总支持周期为 36 个月。关于 Alpha 通道Alpha 通道填补了昔日奇数版本承担的早期测试角色但有一个关键区别Alpha 阶段允许 semver-major破坏性变更。Alpha 发布是经过签名signed、打标签tagged并通过 CITGM 测试的。CITGMCanary in the Goldmine金矿中的金丝雀是 Node.js 维护的工具它会在即将发布的新版本 Node.js 上运行主流开源软件包的测试套件从而在发布前尽早发现生态兼容性问题并通知相关软件包作者。与 Nightly 构建的区别这与 Nightly 构建 不同。Nightly 是直接从main分支自动生成的、未经测试的构建而Alpha 发布不一定包含main上的全部变更。一个变更可能不会被包含进某个 Alpha 版本可能的原因是在 Pull Request 评审期间评审者添加了要求不将本变更回移植的标签例如某个 API 在 Alpha 版本中被运行时弃用runtime deprecated那么真正移除该 API 的变更应当等到下一条发布线再落地在 Alpha 发布准备阶段发布者最终决定哪些提交进入该版本例如某个依赖更新引入了严重缺陷。目标人群与预期面向谁库作者以及需要测试与新破坏性变更兼容性的 CI 流水线。不应用于生产环境。可以预期什么发布经过签名和打标签这与 Nightly 不同API 可能在版本之间发生变化发布节奏是灵活的——Release Team 将根据变更数量和项目需求决定 Alpha 发布的时间和频率。为什么这样做提供了 Nightly 构建所缺乏的质量门槛下的破坏性变更早期反馈同时允许 V8 更新在周期中更早落地。关于哪些 semver-major 提交可以在 Alpha 版本中发布的规则将由 Release Team 定义并记录在 Release 仓库 中。不会改变的内容LTS 支持时长保持相近30 个月迁移窗口被保留LTS 版本之间仍然存在重叠期质量标准不变——相同的测试、相同的 CITGM、相同的安全流程日程依旧可预测——4 月发布10 月 LTS 晋升V8 采用周期不变——Node.js 最新版本仍将包含最多约 6 个月以内的 V8 版本。时间线Node.js 26 时间表现有模式里程碑日期26.0.02026 年 4 月进入 LTS2026 年 10 月进入 Maintenance2027 年 10 月End of Life2029 年 4 月Node.js 26 遵循现有计划这是旧模型下的最后一条发布线。Node.js 27 时间表新模型里程碑日期Alpha 开始2026 年 10 月27.0.02027 年 4 月进入 LTS2027 年 10 月End of Life2030 年 4 月Node.js 27 是新计划下的第一条发布线。未来 10 年版本AlphaCurrentLTSEnd of Life27.x2026 年 10 月2027 年 4 月2027 年 10 月2030 年 4 月28.x2027 年 10 月2028 年 4 月2028 年 10 月2031 年 4 月29.x2028 年 10 月2029 年 4 月2029 年 10 月2032 年 4 月30.x2029 年 10 月2030 年 4 月2030 年 10 月2033 年 4 月31.x2030 年 10 月2031 年 4 月2031 年 10 月2034 年 4 月32.x2031 年 10 月2032 年 4 月2032 年 10 月2035 年 4 月33.x2032 年 10 月2033 年 4 月2033 年 10 月2036 年 4 月34.x2033 年 10 月2034 年 4 月2034 年 10 月2037 年 4 月35.x2034 年 10 月2035 年 4 月2035 年 10 月2038 年 4 月36.x2035 年 10 月2036 年 4 月2036 年 10 月2039 年 4 月需要注意该计划并非最终定稿仍可能被修订。关于项目对各版本支持声明的权威、实时记录请参阅 nodejs/Release 仓库中的schedule.json。新模型在 nodejs.org 官网中的落地新发布计划不仅是项目层面的决策也已经反映在 nodejs.org 网站的源码与页面中可以作为理解该计划的补充佐证状态分类的数据来源releaseData.mjs 中的getNodeReleaseStatus根据 EOL 日期和 LTS 标志把每个主版本归入EOL、LTS或Current三类状态——这正是新模型中每个版本都走向 LTS这一表述在官网上的直接体现majorNodeReleases.mjs 则通过 nodevu 过滤出有明确支持声明即出现在schedule.json中的主版本类型定义types/releases.ts 中的NodeReleaseStatus LTS | Current | EOL定义了站内版本状态的取值范围用户可见的说明previous-releases.mdx 明确写道历史上截至 Node.js 26奇数版本在六个月后停止支持、偶数版本进入 Active LTS自 Node.js 27 起改为年度周期每个主版本在六个月的 Current 阶段外加六个月的 Alpha 阶段之后都会进入 LTSLTS 通常保证 30 个月的关键缺陷修复并建议生产应用只使用 Active LTS 或 Maintenance LTS状态徽章渲染PreviousReleasesTable/TableBody.tsx 使用STATUS_KIND_MAP把每个版本的status映射为对应样式的 Badge让用户在各版本一览表中直接看到 LTS / Current / EOL 状态EOL 的定义eol.mdx 说明了版本进入 EOL 后不再获得任何更新包括安全补丁并列出不升级的代价漏洞无法修复、工具链断裂、生态漂移、合规风险下载页引用current.mdx 在下载页中引导用户前往发布计划页面了解 release schedule 与 LTS 状态。对用户与库作者的建议普通用户 / 只使用 LTS 的团队新计划对你几乎没有影响。只需按新日历每年 4 月新 Current、10 月新 LTS安排升级即可且每个新版本最终都会成为 LTS选择空间反而更大库作者把每个新版本的 Alpha 通道尽早接入 CI。正如公告强调的——如果你只在 LTS 上测试就无法在破坏性变更影响你的用户之前上报问题企业规划者新计划的well-defined特性让跨版本升级窗口LTS 重叠期可以提前数年排定建议按本文未来 10 年表格提前规划升级与资源投入。结语这一变革源于 GitHub issue、Release Working Group 会议以及 2025 年 Chesapeake Collaboration Summit 上的持续讨论并将在伦敦的 Collaboration Summit 上继续深入。项目感谢所有贡献反馈的参与者如果你有任何问题或意见可以在 nodejs/Release 仓库的 issue #1113 中继续讨论。对于希望了解官方实时支持声明的人schedule.json始终是最权威的参考。【免费下载链接】nodejs.orgThe Node.js® Website项目地址: https://gitcode.com/GitHub_Trending/no/nodejs.org创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
