WIP: Roadmap #14
Comments
|
Added note about improving coverage of JS API tests. |
|
Thanks for putting this together. I have a few questions:
|
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.
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.
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.
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. |
|
Closing here as this is now a PR nodejs/node#886 |
_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
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
domainsdebacle).The Tracing WG is still adding things to this list but so far this is:
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:
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
Streams (Immediate)
Localization (Immediate)
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)
The text was updated successfully, but these errors were encountered: