我们的1.0 版本路线图于 2017 年 7 月发布。它描述了我们希望在项目中解决的一系列主题，以及我们认为实现该目标所必需的功能项目。
从那时起，我们通过三次里程碑发布，逐步推进了路线图，其中包含了许多功能。但是仍有一些功能尚未完成，按照目前的进度，还需要 6 个月才能完成。
在发布了 0.20 版本并完成了运行时/编辑器拆分工作之后，我们一直在讨论如何更快地达到 1.0 版本。我们一直在挑战支撑路线图的假设，以查看它们是否仍然成立。
关键的认识是 1.0 版本并非项目的终点。它只是另一个版本，尽管它确实标志着项目的成熟度。
1.0 版本路线图的主要概念是达到功能“完整性”和 API 稳定性的程度。
功能“完整性”
这意味着我们已经解决了用户反馈给我们的主要功能空白。这主要集中在更大的项目上——那些必须在核心运行时中解决的部件，而不是对现有节点进行增量增强。
项目 (0.18)、可持久化上下文 (0.19) 和子流实例属性 (0.20) 都属于此标准。它们各自解决了非常具体的需求，并极大地增强了用户使用 Node-RED 构建的能力。
API 稳定性
每当我们向运行时添加新功能时，它们都会引入新的 API 和扩展点。随着越来越多的用户寻求将 Node-RED 与其现有应用程序集成，或根据自己的需求进行定制，对稳定的 API 有了真正的需求。
运行时/编辑器拆分 (0.20) 工作是这里的主要项目——它通过可重用的 API 暴露了 Node-RED 的更多内部组件。需要做更多的工作来正确地记录这些 API 并提供更多具体的示例说明如何使用它们，但技术工作已经完成。
还剩下什么？
原始路线图中还有三项尚未交付
- 库重新设计——对内置库体验进行彻底改进；Node-RED 用户体验中一个最古老的部分，一直没有得到太多关注。
- 可插拔消息路由——能够将自定义代码插入到消息在节点之间传递的方式。
- 新消息 API——对节点处理消息方式的更新，这将使运行时能够更好地跟踪节点正在做什么，并启用诸如自动超时节点之类的功能。
所有这三项工作都已不同程度地启动，从高级设计工作到实际代码贡献。但它们都需要做更多的工作。
还有一些活动线程涉及原始路线图中未包含的项目，包括
- 子流属性 UI——允许子流定义自己的自定义 UI 来设置其实例属性
- 集成流测试——能够在编辑器中为您的流定义测试用例，并拥有一个可用于验证它们的测试运行器
- 流 Linter——一个命令行工具，可用于根据一组关于流应该和不应该做什么的规则来验证流
我们面临的风险是，随着所有这些活动的进行，我们不断地在达到 1.0 之前发现“多一件事”要做。每个新项目都带来了可能破坏现有稳定性和增加计划时间的风险。
改变计划
考虑到所有这些，我们将进行一些重新优先级排序，以确保我们只专注于 1.0 绝对必要的内容。
这意味着对剩余路线图功能的影响如下
库重新设计
这将为用户在编辑器中与库交互的方式提供急需的外观改进，但不会引入任何新功能。底层 API 将基本保持不变。
我们不会在 1.0 版本中添加插入其他库源的功能，但 UI 更改会为此留出未来空间。
可插拔消息路由
此功能不再是 1.0 计划的一部分。它本身不会为用户增加任何价值。真正的价值在于可以插入的东西——例如交互式流调试器。与其匆忙完成此项目的设计，不如在 1.0 之后完成它，届时我们也可以并行地为它开发一些具体的用途。
新消息 API
我们为此设计已达成一致一段时间了，并且还有一个实现该设计的拉取请求正在等待。但在过去几周，我们发现了一些担忧，即新 API 对于其带来的价值来说变化太大了。鉴于已发布 1900 多个节点模块，我们需要谨慎对待在此领域引入的任何更改。目前正在讨论一种替代设计，它是一个更为温和的更改，提供了所需的大部分功能。
非功能性更改
1.0 版本是项目引起轰动的机会。这将为社区带来新用户，因此我们需要确保一切就绪，以便向他们介绍 Node-RED 并帮助他们入门。
因此，除了 1.0 的技术工作之外，我们还希望对网站进行清理，审查我们的文档，并向菜谱中添加更多内容。如果您正在寻找为项目做出贡献的方式，但不确定是否要深入代码，那么在这个领域有很多可以帮助的地方。
1.0 何时发布？
Node-RED 的**下一个**里程碑版本预计将是 1.0 版本。
目标是 1.0-beta 的第一个版本在 5 月中旬发布，最终版本在 6 月初发布。
然后呢？
正如我们一开始所说，1.0 版本并非项目的终点——它是项目发展中的下一步。
发布的同时，我们将有一个明确的路线图，说明正在进行的工作将把我们带到下一个里程碑及更远。
我们还将把社区调查的结果反馈到计划中——如果您还没有完成调查，请务必完成！
