Node.js v6 LTS 杂谈(一):LTS 与 Node.js 的版本、分支

原作者:洗影

2016 年 10 月 18 日,Node.js v6 LTS (Boron) 发布,这也是 Node.js 启用 LTS 发布计划以来,第一次同时迎来两个 active LTS(v4 与 v6)。这系列文章将讲述 Node.js v6 LTS 带来的一系列变化,本篇主要围绕 LTS 展开。如果读者还对 Node.js LTS 的发布流程不了解,可以先阅读本篇,否则可以直接跳过阅读下一篇关于 Node.js Core 的变动。

Node.js LTS 计划

Node.js core 在 Node.js 与 io.js 合并后,为了保证发布稳定有序,让开发者能够合理安排升级,开始使用 LTS(Long Term Support)来规划发布周期。第一个 LTS 版本是 v4,发布于 2015 年 10 月。在这个规划下,Node.js 的版本相当于 master 分支在特定时间下经过稳定化处理的快照,时间到了就将 master 分支上稳定的部分整合起来,发布新的版本,因此 Node.js 的发布是以时间的流逝为准,在保证兼容性靠拢的前提下跳版本,而不是以兼容性和新特性的多少为准,这也解释了为什么 Node.js 的版本看上去跳得那么快(不是“啊,我们攒了这么多大招,可以发新版了!”而是“啊,四月到了该发版了,我们把攒过的大招过一遍,看有什么够稳定能加进去的,虽然可能这些招不怎么大就是了……”)。值得一提的是,目前的常青浏览器/主流 JavaScript 引擎/ECMAScript 标准/C++ 标准也是采用类似的原则,以时间跨度为基准,从主干上截取稳定特性来进行发布的。

每一个 LTS 都会有一个代号,从元素周期表取元素名,按照字母表排序,挑选出合适的。v4 的代号是 Argon(氩),v6 的代号是 Boron(硼)。

Semantic Versioning - major.minor.patch

Node.js 的版本命名规则遵循 semantic versioning,版本号分为三部分,第一个数字(semver-major)增加,表示有不兼容的改变;第二个数字(semver-minor)增加,表示有保持兼容的新特性;第三个数字(semver-patch)增加,表示有在保持兼容性与特性不变的前提下的改动,比如修复了 bug 或者改进了文档。这个命名规则有利也有弊,此处不赘述,但它的一些矛盾之处使得 Node.js 的命名有一些例外,比如安全更新即使会导致不兼容,为了能够更新到所有 major 版本,也依然是 semver-minor。

一个 LTS 的一生

Node.js v6 LTS 杂谈(一):LTS 与 Node.js 的版本、分支

LTS current: 第一年的四月到十月

目前 Node.js 会在每年四月从 master 截取分支出来,收集足够稳定的特性,发布一个 major 的偶数版本(比如 v6.0.0),作为下一个 LTS 的备选。在当年四月到十月这段 6 个月的期间,这个偶数版本称作“current”(比如 v6.0.0 "current")。在接受社区反馈后,这个版本会修复 bug,增加新特性,不断改善,还可能删掉一些兼容性影响太大的改进,此时这个版本的 minor 版本会不断增加。开发者可以利用这段时间,用这个候选 LTS 版本在线下测试自己的应用,并将兼容性问题与 bug 反馈给 Node.js 的开发者。

LTS active: 第一年的十月到第三年的四月

到了当年十月,这个偶数版本就会成为 LTS(比如 v6.9.0 "LTS"),此时它也被称为 "active LTS"。在此后 18 个月的 active 期间,这个版本几乎不会再有任何不兼容的变更,除了安全相关的 OpenSSL 以外其他的依赖(比如 v8)也不会进行大的更新。这段时间内开发者可以将线上的 Node.js 升级到这个稳定的 LTS 版本,并使用 Node.js 的新特性进行迭代。

LTS maintenance: 第三年的四月到第四年的四月

经过 18 个月的 active 时期后,在第三年的四月,这个版本将会迎来最后 12 个月的 maintenance 时期,这个时候它的更新只有安全更新和 bug 修复。由于 Node.js 每年十月出一个 LTS,因此在这个版本 active 时期的 2/3 的节点,就会有一个新的 active LTS 诞生(目前就处于 v4 LTS 还剩下 6 个月的 active 时,v6 LTS active 发布的时间点)。等到它的 active 时期结束时,开发者已经有 6 个月的时间过渡到下一个 active LTS。即使开发者更新的进度比较慢,也还有 12 个月的 maintenance 时间,抓紧进行升级。12 个月后,这个 LTS 将会结束它的寿命,不再迎来任何更新。因此,每个偶数版本,都会有 3 年的寿命。

Node.js 应用开发者怎么选择?

对于追求稳定性的 Node.js 应用开发者来说,只需要每年十月一个版本成为 active LTS 的时候线上跟进升级即可,也就是每 12 个月升一次 major 版本,每次升级的版本还有 18 个月 + 12 个月的寿命,中间跟进 minor 和 patch 的时候不用太担心兼容问题。目前的推荐是最好在一个 active LTS 出来的 12 个月内完成线上的升级(因为 12 个月后会出下一个 active LTS)。进度落后的话,妥协到 18 个月,这个 LTS 的 active 时期结束前也可以。再赶不上,起码要在 30 个月内这个版本结束寿命之前升级完,否则连安全更新也没有了。

担心直接升级遇到的兼容问题较多的话,则可以在每年四月偶数版本新出来的时候,提前在线下进行测试和升级准备,将问题反馈到社区(当然如果没空也不需要管这一步),并不断跟进,十月再升线上版本。这样线上下都是 12 个月升一次 major,只不过时间点不同。虽然线下需要跟进的兼容性问题多了一些,但同时也可以通过反馈让自己的兼容性需求被社区照顾到。

热衷于尝试新特性,或者不在生产环境使用的实验性项目,则可以尝试每年十月发布的奇数 major 版本。每个奇数版本只会维护 8 个月,而且不会有 LTS 那样的兼容性保证,但Node.js 的开发者会利用这个版本为下一个 LTS 做准备,因此它会有更多大胆的尝试,比如更频繁的 v8 更新(意味着更多的 ECMAScript 新特性实现以及性能优化)。

因此,现在还在线上使用 v4.x 的开发者,已经可以准备升级到 v6.x 了。如果你的线上应用还在使用 LTS 计划启用前发布的版本,如 v0.12.x,也最好抓紧升级到 v4.x 或者以上,因为 2016 年 12 月之后 v0.12.x 将不会再有任何安全更新,更早的版本就更没有了,主要是 OpenSSL 的漏洞将不会被修复,这些应用将会暴露在各种安全风险之下。一旦升级到 v4.x 或更高,今后的升级将会相对容易许多,平时只要记得跟进 minor 或者 patch 即可,或者懒一点的只需要关注安全更新。

这跟 Node.js 的源代码是怎么对应的?

首先,Node.js 的 Github Repo 有一个 master 分支,大部分的 commit 是通过 PR 提交到这个分支上的。根据这些 commit 是否改变了兼容性或者引入了新特性,它们会被打上 semver-major 或者 semver-minor 的标签。

在每年四月前需要准备 LTS 的时候,Node.js 会从 master 分支截取一个新的分支出来,假如这个是 v6,那么这个分支就叫 v6.x-staging。之后与这个 LTS 相关的修改/打算进入这个 LTS 的修改,比如 bug 修复等,还是提交 PR 到 master,但需要加一个 tag lts-watch-v6.x。被合并到 master 之后,这些变动会被负责发布的人挑出来,合并到 v6.x-staging。当到了四月的某一天,v6 的第一个版本可以发布的时候,负责发布的人会创建一个 v6.x 分支,从 v6.x-staging 再挑出变更合并进来。从四月到十月,对 v6 的所有修改,无论是 minor 或者 patch,依然先提交 PR 到 master,然后再被挑出来合到v6.x-staging,发版本时再进入 v6.x。这样,master 总是保留着最新的变动。而其他版本相关的分支,都是从 master 上挑出适合发版本的 commit,混合出来的缩影,v6.x-staging 保留着 v6.x LTS 相关的修改,v6.x 保留每一次 v6 发布的版本。除了负责处理分支的人以外,其他开发者是不会动这些版本相关的分支的。

Links

预告

接下来的文章将会介绍 Node.js v6 LTS 带来的一系列更新,包括 Node.js Core 的变动,V8 的变动,其他依赖(libuv、npm、OpenSSL)的变动。

---- 广告时间 ----

欢迎使用 alinode,基于 Node 运行时的应用性能管理解决方案,我们已经跟进 v6 LTS,版本对应关系请点这里

上一篇:每天学点SpringCloud(五):如何使用高可用的Eureka


下一篇:[译]V8发布4.9版本