为什么build议通过v6.2.0的node.js v4.4.5“对于大多数用户”？
几年前，我使用了node.js作为开发项目，而这个应用程序暂时有些“不可用” – 它需要保持在线状态，需要保持安全，但是不需要太多的关注。 它目前在node.js v0.10.32上运行，但现在我想投资于“最终”迁移到长期支持（LTS）版本，以便在可预见的将来更容易维护。
乍一看，node.js主页看起来像v4.4.5显然是唯一可用的LTS版本：
但是，如果我点击LTS时间表链接，它会讲述一个不同的故事。 据我所知，node.js的第6版也将被定为LTS版本，支持比版本4晚一年结束。
鉴于：
- v6.2.0是一个版本化版本
- v6据称将在2019-04-01之前接受LTS维护
- 从理论上讲 ，v6.x中的任何更改都不会破坏向后兼容性
为什么我会打扰升级到V4而不是V6？ 似乎v4买了一年的安全补丁，但没有额外的兼容性保证？
感谢jasnell和TheAlphaNerd在GitHub上耐心地回答了我的尖锐问题，下面是我对如何处理node.js“长期支持”版本的理解：
-
所有基于偶数主分支的版本都是其他项目可能称为“长期支持”的版本。 他们承诺至less30个月的支持，从第一个“削减”可用（例如一个包装的v6.0.0版本）。
-
但是，node.js维护者将“LTS”看作是版本types的更多发布阶段 。 虽然他们打算在主要分支机构正在积极改进（见下文“当前”）阶段时做出的轻微/补丁发布阶段是稳定和向后兼容的，但在现实世界中，他们可能会犯错误。
所以他们把发展划分为三个不同的阶段 ：
- CURRENT：新function（以及错误修复和安全补丁）
- 主动LTS：错误修复（和安全补丁）
- 维护：只有安全补丁
奇数主要版本只有第一阶段被留下之前。 偶数主要版本 – 我们在这里最关心的 – 经历三个阶段 。
CURRENT阶段从第一个公开发布开始，并在30个月的支持窗口开始时钟滴答。 他们可能会添加重要的新function，这在理论上应该是向后兼容的，但在实践中可能会出现一些问题（新的bug被添加，更改为不明确的行为，修复了一个旧的bug，等等）。 ）
然后在某个时候，团队决定将主要开发工作转移到一个短命的奇数主要分支（大概是当他们需要故意破坏向后兼容时）。 此时，偶数分支移动到ACTIVE LTS，他们对所做的更改变得更为谨慎：主要是修正了错误。 所以如果你真的想要稳定的话，现在是时候用一个特定的版本来“登上”了。
最后，它进一步移动到维护阶段，在这个阶段代码只是为了应对最重要的错误（思考：安全补丁）。 但是到那时LTS“阶段”可能已经有了新的版本。
所以现在在网页上的select是在两个偶数分支“v4.4.5 LTS”和“v6.2.0 current”之间。 如果较新的分公司是奇数编号，那么对于需要长期支持的生产部署来说，这将不是一个好的select。
我的实际select甚至更复杂一些：
我可以简单地留在v0.10上，直到十月份才能得到关键的修复。 或者碰到v0.12，直到今年年底。 但是，这些都没有得到什么好处，所以我就排除了。
我可以部署v4.4.5，它现在仍然可以修复一般的bug，并且会在一段时间内获得安全修复。 这应该给我最稳定的安装。 虽然支持周期已经过去了一半，但是现在我已经错过了这个机会来赶上v5和v6已经发生的一些重大变化。
我倾向于部署v6.2.0，假设我所有的依赖项都支持它。 这不仅使我获得了长达一年的“剩余生命”的期限，而且使我完全赶上了从1.0版到现在之间引入的任何突破性变化。 （这也让我可以访问任何有用的新function – 但在这种情况下，我没有机会利用它。）我承担的风险是，当我更新到任何假设的v6.2.1或v6.3.0或除此之外，它可能会意外地产生一些不好的意外。
在我的情况下，我宁愿现在处理v5和v6已经引入的主要故意改变，然后希望从现在一直到2019年4月，所有的设置（或至less只是轻微的痛苦）。
