WIP: Roadmap

[mikeal]

_This is still a work in progress. Feedback is still rolling in but there have been enough commonalities in the feedback that it's worth starting to put together a roadmap._

This is only an outline, the final roadmap will need some additional visual elements to it in order convey some of the complexity. The work is not targeted at specific version numbers, the version will increment when things land based on semver. The work is not strictly time based (Q1, Q2, etc) because we've seen things move too fast to assume they can't be done until 6 months in the future. Instead we have immediate priorities (things we are focused on now) and mid term priorities (possible WIP but awaiting the immediate priorities to be cleared).

Stability and Compatibility

Stability and Compatibility are not an item on the roadmap because they are baked in to the process that we accept and release code under. No release should be considered unstable and breaks in compatibility should be rare or, ideally, never happen.

Our full stability and compatibility policy is still being drafted.

Channels

• Release - Stable production ready builds. Unique version numbers following semver.
• Canary - Nightly builds on next-generation v8 + changes landing to io.js. No version designation.
• NG - Nightly builds of "Next Generation." No version designation.

NG (Next Generation)

If we are going to support ES6 modules we have an opportunity to offer them a new ES6-centric API without breaking compatibility with existing modules using the current API. What that API looks like and how it is implemented doesn't have a place to live at the moment and it's a drastic enough change that it will need many cycles of integration before it ships. Rather than try and shove this work in to a short cycle in the Canary pipeline we should instead give this it's own channel and even, eventually, its own roadmap (it is far too early to do so now).

This will help us grow a community that is engaged in cutting edge future work without getting in the way of our continued incremental improvements to a reliable and stable release channel.

Immediate Term

Debugging and Tracing

In terms of pain points, debugging is one of the first things from everyone's mouth, both developer and enterprise.

The strategy here is to build on the work v8 has done adding many many trace points and extending what is possible using AsyncWrap. Once we've extended what is possible Evangelism can help spread that message and promote the activity in the community who is building and releasing new tools and strategies for debugging and tracing live applications. The goal is to build a healthy debugging and tracing ecosystem and not to try and build any "silver bullet" features for core (like the domains debacle).

The Tracing WG is still adding things to this list but so far this is:

• AsyncWrap improvements -- basically just iterations based on feedback from people using it.
• async-listener -- userland module that will dogfood AsyncWrap as well as provide many often requested debugging features.
• Tracing
  • Add LTTNG Tracing for Linux.
  • Unify the Tracing endpoint.
  • New Chrome Debugger -- Google is working on a version of Chrome's debugger that is without Chrome and can be used with io.js.

Ecosystem Automation

In order to maintain a good release cadence without harming compatibility we must do a better job of understanding exactly what impact a particular change or release will have on the ecosystem. This will require new automation that can find breaks in the module ecosystem.

The initial goals for this automation are relatively simple but it will create a baseline toolchain we can continue to improve upon. It should be able to produce:

• A list of modules that no longer build between two release versions.
• A list of modules that use a particular core API.

We will also start using coverage tools against node's JS API and begin adding tests which cover the current API in more depth.

Improve Installation and Upgrades

• Host and maintain registry endpoints for Homebrew & Apt
• Document installation and upgrade procedures with an emphasis on using nvm or nave for development and to use our registry endpoints for traditional package managers.

Streams (Immediate)

• Fix all existing compatibility issues.
• Simplify stream usage and creation to avoid user error.

Localization (Immediate)

• Start at least two localization working groups.
• Build documentation tooling with localization support built in.
• Ship w/ ICU (Bert is currently working on getting the size down).

Mid Term

Performance

We can assume that we won't make it out of the debugging additions without any performance impact. Once we're happy with the debugging work done to core we should prioritize performance work.

Items TODO

Security

JavaScript has done a great job of creating a "safe" VM environment but there is still plenty more to do in order to make io.js "the most secure application platform in the world" which is a goal. The effort here can be divided in to two buckets: the security of core and its dependencies and security in userland/npm.

Items TODO

Streams (Immediate)

• Implement WHATWG-Streams and provide feedback to the standardization process
• TODO: Figure out what Stream look like in NG

[mikeal]

Added note about improving coverage of JS API tests.

[chrisdickinson]

Thanks for putting this together. I have a few questions:

• What is a channel, in terms of this proposal?
• What is the relationship between a channel and a branch? (The NG channel prompts this question.)
• What mechanism keeps NG from turning into another v0.12 branch?
  • Why not go the feature flag route?
• Is the proposal to put all breaking/refining JS API changes into NG? That is, is the proposal suggesting that we use ES0xF module syntax as a gate to new functionality? (I saw mention of the NG concept in another thread, but otherwise this is the first I've seen of that proposal. Am I missing context from NodeSummit?)
• What is the "next-generation v8" that canary uses? Is this channel continually updated to track the current unstable v8 on a daily basis? A weekly basis? (My release cycle proposal ran into similar fogginess with this. My current thinking is "just upgrade v8 like any other work going into the project" and not special case it in release channels at all.)

[mikeal]

What is a channel, in terms of this proposal?

A channel is mostly a policy for what goes in a release and how it is built. For instance, release isn't just the current line of development but also any patch releases for old lines. Basically, anything that actually has a semver version attached to it is in the release channel. The other two are nightlies only and their sole purpose is for people to do testing and experimentation.

What is the relationship between a channel and a branch?

For NG and Canary it is probably 1-to-1 but release is another story because it also includes patch releases of older development lines.

I've intentionally separated the technical details here from the channel descriptions. Each channel has a purpose, the technical means by which we produce them should be iterated on without re-defining or re-messaging the channels.

Is the proposal to put all breaking/refining JS API changes into NG?

Yes, because we can do so without breaking any existing modules. I don't think this idea has been mentioned publicly before but I'm pretty sure that the first time I heard about the concept was from @isaacs more than a year ago. At the time I thought it was a terrible idea but seeing the level of engagement around features using new JS standards I think it's the only rational course.

The most important part to me is that we give people who are interested in a next-generation ES6/7 centric platform a place to contribute that work and be productive without effecting the work we're currently doing improving the existing production ready platform.

What is the "next-generation v8" that canary uses

It should be whatever unstable line the v8 team is producing releases for. The only purpose here is to give us some insight in to ramifications of v8 changes while they are still under active development. Ideally, with our new collaboration w/ v8/Google, we'll see work going in that is relevant or possible only for io.js and we'll want a good way to experiment and test that work.

[mikeal]

Closing here as this is now a PR nodejs/node#886