为什么在v6.2.0上建议“对于大多数用户"使用node.js v4.4.5? [英] Why is node.js v4.4.5 recommended over v6.2.0 "for most users"?

问题描述

几年前，我在开发项目中使用了node.js，该应用暂时处于滞销状态–它需要保持在线状态，需要保持安全性，但不需要太多注意.它目前在node.js v0.10.32上运行，但是我现在想投资到长期"迁移到长期支持(LTS)版本，以便在可预见的将来更容易维护.

I used node.js for a development project a few years ago, and this app is somewhat "mothballed" for the time being — it needs to stay online, it needs to stay secure, but it shouldn't need much attention. It is currently running on node.js v0.10.32, but I would now like invest in a "final" migration to a Long Term Support (LTS) release so it will be easier to maintain for the foreseeable future.

乍一看，node.js主页看起来好像是v4.4.5显然是唯一可用的LTS版本:

At first glance, the node.js homepage makes it look like v4.4.5 is obviously the only available LTS release:

但是，如果我单击该 LTS时间表链接，它会讲述一个不同的故事.据我所知，node.js的第6版也将定为LTS版本，该支持将比第4版晚整整一年.

However if I click that LTS schedule link, it tells a different story. As far as I can tell, version 6 of node.js is also slated to be an LTS release, with that support ending a full year later than version 4 will be.

鉴于:

• v6.2.0是版本发行版
• v6据说将在2019年4月1日之前接受LTS维护
• 理论上 v6.x中的任何更改都不应破坏向后兼容性

• v6.2.0 is a versioned release
• v6 is purported to receive LTS maintenance until 2019-04-01
• theoretically no changes in v6.x should break backwards compatibility

我为什么要麻烦升级到v4而不是v6?好像v4可以为我少买一年的安全补丁，但是没有其他兼容性保证吗?

Why would I bother upgrading to v4 instead of v6? Seems like v4 buys me one less year of security patches, but no additional compatibility guarantees?

推荐答案

感谢 jasnell 和TheAlphaNerd 耐心地在GitHub上回答了我的尖刻问题，这是我对如何处理node.js长期支持"发布的理解:

With gratitude to jasnell and TheAlphaNerd who patiently answered my acerbic questions over on GitHub, here's my understanding of how node.js "long term support" releases are handled:

• 所有基于偶数主分支的发行版都是，其他项目可能将其称为长期支持"版本.从第一个剪切"版本(例如打包的v6.0.0版本)开始，他们将获得至少30个月的支持.

• All releases based on an even-numbered major branch are what other projects might call a "long term support" version. They are promised at least 30 months of support from the first "cut" made available (e.g. a packaged v6.0.0 releases).

但是，node.js维护者将"LTS"视为版本阶段而不是版本 type .尽管他们打算在主要分支处于积极改进状态(请参见下面的当前")时使次要/补丁发布保持稳定并向后兼容，但在现实世界中，它们可能会出错.

However, the node.js maintainers see "LTS" as more of a release phase than a version type. While they intend for minor/patch releases made when a major branch is in its active improvement (see "CURRENT" below) phase to be stable and backwards compatible, in the real world they might make mistakes.

因此，他们将开发划分为三个不同的阶段:

So they divide development into three distinct phases:

1. 当前:新功能(以及错误修复和安全补丁)
2. 主动LTS:错误修复(和安全补丁)
3. 维护:仅安全补丁程序

奇数编号主要版本只有第一阶段，然后才被抛在后面. 偶数主要版本(我们在这里最关注的版本)经历了所有三个阶段.

Odd-numbered major versions get only the first phase before being left behind. Even-numbered major versions — the ones we're mostly concerned about here — go through all three phases.

CURRENT阶段从第一个公共发行版开始，并在30个月的支持窗口中开始计时.它们可能会添加重要的新功能，从理论上讲应该向后兼容，但实际上可能会出现一些问题(添加了新的错误，对定义不明确的行为进行了更改，修复了您以前无法很好解决的旧错误等). )

The CURRENT phase starts with the first public release, and starts the clock ticking on the 30-month support window. They may add significant new features, which should in theory be backwards-compatible but in practice may turn up some issues (new bug gets added, change made to poorly-defined behavior, they fix an old bug you had worked around poorly, etc.)

然后，团队决定将主要开发工作移至短寿命的奇数主分支(大概是在需要有意打破向后兼容性的时候).那时，偶数分支转移到ACTIVE LTS，并且他们对所做的更改要更加小心:主要是错误修复.因此，如果您真的想要稳定性，那么是时候使用特定版本了.

Then at some point the team decides to move the main development effort to a short-lived odd-numbered major branch (presumably when they need to intentionally break backwards compatibility). At that point the even-numbered branch moves to ACTIVE LTS and they get much more careful with the changes they make: primarily just bug fixes. So if you really want stability, this is the time to get "on board" with a particular release.

最终，它甚至更进一步进入了维护"阶段，在此阶段，仅针对最严重的错误(例如:安全补丁)才对代码进行触摸.但是到那时，LTS的阶段"可能已经有一个新版本.

Eventually it moves even further to the MAINTENANCE phase, where the code is touched only in response to the most critical bugs (think: security patches). But by then there's probably a new release in LTS "phase" already.

因此，现在主页上的选择是在两个偶数分支"v4.4.5 LTS"和"v6.2.0 current"之间.如果较新的分支为奇数，则 将不是一个需要长期支持的生产部署的理想选择.

So the choice on the homepage right now is between two even-numbered branches, "v4.4.5 LTS" and "v6.2.0 current". If the newer branch were odd-numbered then it would not be a good candidate for a production deploy where long-term support is desired.

我的实际选择甚至更加复杂:

My actual options are a bit more complex even:

我可以简单地停留在v0.10上，它将在10月之前获得关键修复.或者提高到v0.12，直到年底为止.但是这些人都没有给我带来太多好处，因此我将其排除在外.

I could simply stay on v0.10 which will get critical fixes until October. Or bump up to v0.12 to get those until the end of the year. But neither one of those gains me much, and so I'll rule them out.

我可以部署v4.4.5，该版本现在仍将获得常规的错误修复，并且将在相当长的一段时间内获得安全修复.这应该给我最稳定的安装.支持周期已经结束了一半，当它用完时，我现在将错过这个机会来赶上v5和v6中已经发生的一些重大变化.

I can deploy v4.4.5 which will is still getting general bug fixes right now, and will get security fixes for quite a while yet. This should give me the most stable install. The support cycle is getting to be halfway over already, though — and when it runs out I'll have missed this opportunity now to catch up with some of the major changes that have already happened in v5 and v6.

假设所有依赖项现在都支持v6.2.0，我倾向于部署v6.2.0.这不仅使我获得了一年的剩余生命周期"，而且使我完全了解了v0.10至现在之间引入的任何重大更改. (这也使我可以使用任何有用的新功能-但在这种情况下，我没有机会利用它.)我冒的风险是，当我更新到任何假设的v6.2.1或v6.3.0或除此之外，它可能会意外产生一些不好的惊喜.

I am leaning towards deploying v6.2.0, assuming all my dependencies support it right now. This not only buys me a year longer term of "lifecyle remaining", but also gets me fully caught up with any breaking changes that were introduced between v0.10 and now. (It also gets me access to any useful new features — but in this case I don't have a chance to take advantage of it.) The risk I take is that when I update to any hypothetical v6.2.1 or v6.3.0 or beyond that comes along, it might accidentally yield some bad surprises.

就我而言，我现在想解决v5和v6已经引入的主要的有意更改，然后希望从现在一直到2019年4月都已设置好(或至少只有很小的痛苦).

In my case I'd rather deal now with the major intentional changes that v5 and v6 have already introduced, and then hopefully be all set (or at least only minor pain) from now all the way until April 2019.

这篇关于为什么在v6.2.0上建议“对于大多数用户"使用node.js v4.4.5?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！