search

nodejs / roadmap

This repository and working group has been retired.
135 stars 42 forks source link

WIP: Roadmap #14

Closed mikeal closed 9 years ago

mikeal commented 9 years ago

_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

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:

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:

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

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)

mikeal commented 9 years ago

Added note about improving coverage of JS API tests.

chrisdickinson commented 9 years ago

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

mikeal commented 9 years ago

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 commented 9 years ago

Closing here as this is now a PR https://github.com/iojs/io.js/pull/886