随着 1.1.0 版本的发布，我们的注意力转向了下一个版本。但在我们推进待办事项列表中的下一个项目之前，现在是时候考虑更宏观的画面了。

我们在去年 10 月达到了 1.0 的里程碑。这对我们来说是一个重要的节点，花了不少时间才达到。而我们又花了 9 个月才发布下一个版本。这个延迟并不理想，因为它意味着许多新功能已经搁置了几个月，等待发布。

这是一个开源项目不幸的结果，它不能想当然地认为任何人的参与都是理所当然的。虽然我很幸运能够将大部分日常工作投入到这个项目中，但对于许多其他贡献者来说并非如此。

我们对发布时间表的安排一直比较宽松。我们没有提前设定太远的目标日期，只是在某个时候决定我们有“足够”的新内容来发布新版本。

在 1.0 版本发布之前，我们偶尔也会进行不应该在次要版本号发布中进行的更改。例如，放弃对旧版本 Node 的支持。当项目版本是 0.x 时，你勉强可以这样做，但现在我们是 1.x 版本的项目，我们需要更加小心。

就目前而言，我们技术上仍然支持在 Node.js 8.x 上运行——尽管该版本的 Node 已于今年年初停止维护。而且我们肯定关注到 Node 10.x 将于明年 4 月底停止维护的事实。

虽然我们肯定不推荐，但我们理解有些用户停留在旧版本上，如果可以避免，我们不想无谓地破坏他们。

但我们也不能因此持续限制自己无法在核心运行时中使用新的 Node.js 功能。

我们还认识到，对于那些将 Node-RED 整合到其商业解决方案中的公司，他们需要对 Node-RED 特定版本将获得多长时间的支持有一定程度的信心。

因此，考虑到所有这些，以下是关于我们未来如何管理发布的当前**提案**。

在底部，图表显示了当前 Node.js 版本的发布日期。如果您在任何生产环境中使用 Node.js，您需要了解这些日期。

顶部显示了 Node-RED 的拟定发布时间表。

总而言之，我们计划每三个月发布一个次要版本（例如，1.1 → 1.2）。维护版本（例如 1.1.0 → 1.1.1）将继续按需发布。

2021 年 4 月底，当 Node 10.x 达到其生命周期结束时，我们将发布 Node-RED 2.x，它将**放弃**对 Node 8.x 和 Node 10.x 的支持。

然后，1.x 系列将进入维护模式。它将只接收错误修复和安全更新。如果有很好的理由并且有人可以完成工作，新功能可以从 2.x 向后移植。

2.x 系列将继续积极开发，大约每三个月发布一个次要版本，直到 2022 年 4 月 Node 12.x 达到其生命周期结束。然后我们发布 Node-RED 3.x，循环继续。1.x 系列将在 3.x 发布后不久达到其生命周期结束。具体的时间安排我们将需要进一步讨论。

此提案意味着

• 我们有规律的发布周期——将新功能及时提供给用户。
• 我们有一个时间表来帮助我们确定待办事项的优先级和计划。
• 我们可以提供具有明确生命周期结束的长期稳定版本。
• 我们有一个计划，使我们每年可以进行一次潜在的重大更改。

重要的是要记住，这个计划并非没有风险。它假设项目有足够的贡献者来帮助实现它。当我们有多个流需要维护时，这一点变得尤为重要。

我们希望公布的发布时间表能鼓励人们做出贡献，无论是代码、文档、测试还是仅仅是一般的反馈。

我们将在接下来的几个月里观察情况——我们有时间到四月，之后我们将会有多个活跃的流。如果有什么不起作用，我们不得不重新考虑这个计划，那么我们就会这样做。

我已将此计划的摘要添加到网站的“关于”部分以供将来参考。