随着 0.17 版本的发布，我们已将注意力转向了下一步的计划。我们决定花一些时间来规划项目的发展方向，而不是直接开始为下一组功能编写代码。
使用我们的 Trello 白板来追踪个别的增强功能和更大的“史诗级”任务，这对于展示我们心中的想法非常有帮助。但是 Trello 白板缺乏一个能够将这些零散卡片描绘成一个完整画面的叙述。
关于版本号
我们也在考虑版本号的问题。自项目开始以来，我们一直遵循语义化版本（semantic versioning）的规则。版本号由三个部分组成：主版本号.次版本号.修订号。每个部分何时递增的规则非常简单：
- 当进行向后兼容的错误修复时，递增“修订号”。
- 当以向后兼容的方式添加新功能时，递增“次版本号”。
- 当进行不兼容的 API 更改时，递增“主版本号”。
这给了我们一个不去担心 1.0 版本的借口。我们一直专注于将每个版本作为对前一个版本的增量改进，并尽最大努力确保我们不会进行不兼容的更改。正因如此，一个四年前从 0.3 版本导出的流程，至今仍然可以导入到今天的 0.17 版本中使用。
但是 1.0 版本具有特殊的意义。SemVer 规范是这样说的：
如果你的软件正在生产环境中使用，它可能已经应该是 1.0.0 了。如果你有一个稳定的、用户已经开始依赖的 API，你应该发布 1.0.0。如果你非常担心向后兼容性，你可能早就该是 1.0.0 了。
如今，有很多用户在生产环境中使用 Node-RED——这是我们完全支持的。但我们也听说有些用户因为我们没有那个传说中的 1.0 版本号而对在生产环境中使用犹豫不决。
所以，是时候谈谈 1.0 了。
迈向 1.0
我们一直在问自己这样一些问题：要达到 1.0 版本需要做些什么？我们希望先完成白板上的哪些项目，以及按什么顺序完成？
为了帮助我们思考，我们确定了几个希望解决的高层次主题：
- 工作流 - 如何让单个开发者更高效
- 协作 - 在开发者团队中工作
- 可扩展性 - 提供正确的扩展点和 API 来适配 Node-RED
- 伸缩性 - 更容易地创建能够扩展以处理越来越大工作负载的流程
- API 稳定性 - 提供一个可以长期开发的稳定基础
在这些主题的背景下思考白板上的功能，引导我们制定了这份路线图。大多数单独的项目对于那些一直关注 Slack 或邮件列表讨论的人来说都很熟悉，但其中也有一些讨论不多的新内容——比如“项目”（Projects）和新的“节点消息传递 API”（Node Messaging API）。
你会注意到，这个路线图上没有确定的时间表；它代表了大量的开发工作，并且在最终设计上还有一些悬而未决的问题。但我们的目标是在今年年底前达到 1.0 版本。
下面的幻灯片更详细地介绍了这个路线图，并包含了大量围绕它们给编辑器带来的用户体验变化的设计工作。
一个起点
这个路线图是社区内部讨论的起点。你认为它能把我们带到正确的位置吗？我们是否遗漏了什么？
欢迎所有反馈——我们依靠社区来帮助我们保持项目朝着正确的方向前进。请通过邮件列表或 Slack 联系我们，让我们知道你的想法。
了解更多
下周一，7月24日，IBM 将在旧金山举办两场关于 Node-RED 的活动。一场是动手实践工作坊，另一场是见面会，我将在会上更多地谈论这个路线图。
这两场活动都是免费的，注册也很简单——点击下面的链接，来打个招呼吧！
之后，我也会在接下来的一周参加 Node Summit——在 JS 基金会的 Day Zero 活动中有一个环节，并在本周余下的时间里与大家交流。
