« 回到博客列表

Node.js 9.0.0 发布

Tags: nodejs

Node.js 发布计划

Node.js 从 5.0 开始一直遵循着半年一个大版本的发布周期,每年 4 月左右发布一个主版本号为偶数的 LTS(Long-Term-Support)版本,每年 10 月左右发布一个主版本号为奇数的非 LTS 版本。

新版本发布后的半年内被称为“当前版本”,起初可能会遇到较多的向下兼容问题,早期升级的开发者可能会受到短期的“生长痛”影响,经过若干小版本的更新后会逐渐趋于稳定。

每年 10 月的奇数版本发布后,同年 4 月发布的偶数版本进入 LTS 阶段,为期一年半。期间除非 Release 工作组同意,不再添加新特性,只对现有功能进行完善,变更内容仅限于:

  1. 修复 Bug
  2. 安全性升级
  3. npm 升级(主版本号不变)
  4. 相关文档的更新
  5. 性能优化(基本不会影响已有的应用程序)
  6. 会引入大量繁琐恶心的代码(对已有应用程序的影响很低),但是对未来做向下兼容补丁有利的变更

最后还有 1 年时间的维护期,期间除非是非常严重的 Bug 或安全性问题,不再有改动,对文档的修改也需要授权才可以。LTS 版本的生命周期共计 3 年,之后不再维护。

奇数版本通常会相对激进地引入一些新的语法和特性,变化也会比较快,主要用于对一些新特性的试错和测试,稳定性并非追求的第一目标(毕竟只活半年)。由于变化较快,风险非常不可控,不推荐在生产环境使用奇数版本的 Node.js,想尝鲜的开发者们,请务必做好足够的思想准备,迎接不稳定的功能变更,并确定自己有足够能力应对升级引发的各种问题(已有代码、开发环境和工具受升级影响无法正常使用等)。建议先在个人设备上有了一定实践,踩掉一些坑,感觉自己能 hold 住了,再考虑迁移到公司设备上。

偶数版本主要考虑用于生产环境,稳定性的优先级会比较高,但并不排除引入断层升级的可能性(例如 Node.js 8.0 升级更新了 npm 到 5.0,新版 npm 对用老版本安装的依赖没有做好相应的处理,导致大量从 4.x 升级过来的用户直接没法干活了,只能通过全新安装依赖来解决。官方 Github 上有人维护了一长串的 Known Issue,其中影响较大的几个问题至今没能得到解决,可能官方也不打算管了)。升级建议:

  1. 新版本刚发布先别急更新到生产环境,找测试设备踩一遍坑先
  2. 多关注官方 Github 上的 Issue
  3. 持续关注最新动态,因为最多 3 年时间,老版本就退休了,升级是早晚的

Node.js 9.0.0 的主要变化

本次升级并没有太多令人兴奋的点,官方并不希望大版本的更新导致严重的断层,因此新特性、语法会在次版本更新中逐渐被加入。主要变化如下:

Node.js 9.0.0 发布之后

按照官方的发布计划,9.0 的发布,意味着 8.x 进入 LTS 阶段,7.x 彻底退出舞台,6.x 的 LTS 还有半年结束。也就是说,差不多是时候考虑往生产环境部署 Node.js 8.x 了。

番外

或许是因为大部分人都是实用主义者,大家心里都很清楚,奇数版本就是用来试错的,只有偶数版本才会被用于生产环境,因此大部分人都会关注“有用”的偶数版本,而忽略“与我无关”的奇数版本。从搜索引擎对“node 7”和“node 8”的收录情况来看,关于 node 7 的讨论非常少,除了一些主流媒体报道了一些版本发布的消息,基本搜不到什么有价值的内容,而关于 node 8 的讨论就明显要多一些。

倒不是想说这有什么不对,每个人的精力都有限,实用主义没什么不好。作为一名大前端技术的爱好者,同时也是一名职业的开发者,我个人是比较乐于去了解和尝试新技术的,即便它最后并没能够成为主流,但只有亲自尝试了,才有发言权说这东西究竟如何。也只有亲自参与其中,才能真正领略到开源世界众多开发者们的智慧,思考的过程才是真正学到东西的过程。

希望本文能够为“或许注定要被忽略”的 Node.js 9.x 多少贡献一点点的关注度吧。