Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Roadmap #886

Closed
wants to merge 8 commits into from
Closed

Roadmap #886

Changes from 7 commits
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
773b002
Initial roadmap commit.
mikeal Feb 19, 2015
b67282f
Various edits based on feedback.
mikeal Feb 19, 2015
5304e8d
Removing reference to Python 3.
mikeal Feb 19, 2015
f1b89e9
Stop codeifing io.js
mikeal Feb 19, 2015
d058d50
Clarifying Canary Channel.
mikeal Feb 19, 2015
d558cf8
We might not actually implement WHATWG streams.
mikeal Feb 19, 2015
2f715ee
Much better stability language from @chrisdickinson
mikeal Feb 19, 2015
dd2441d
Adjusting for feedback from @chrisdickinson.
mikeal Feb 20, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
92 changes: 92 additions & 0 deletions ROADMAP.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,92 @@
# io.js Roadmap

***This is a living document, it describes the policy and priorities as they exist today but can evolve over time.***

## Stability Policy

The most important consideration in every code change is the impact it will have, positive or negative, on the ecosystem (modules and applications).

io.js does not remove stdlib JS API.

Shipping with current and well supported dependencies is the best way to ensure long term stability of the platform. When those dependencies are no longer maintained io.js will take on their continued maintenance as part of our [Long Term Support policy](#long-term-support).

io.js will continue to adopt new V8 releases.
* When V8 ships a breaking change to their C++ API that can be handled by [`nan`](https://github.com/rvagg/nan)
the *minor* version of io.js will be increased.
* When V8 ships a breaking change to their C++ API that can NOT be handled by [`nan`](https://github.com/rvagg/nan)
the *major* version of io.js will be increased.
* When new features in the JavaScript language are introduced by V8 the
*minor* version number will be increased. TC39 has stated clearly that no
backwards incompatible changes will be made to the language so it is
appropriate to increase the minor rather than major.

No new API will be added in *patch* releases.

Any API addition will cause an increase in the *minor* version.

### Long Term Support

io.js supports old versions for as long as community members are fixing bugs in them.

As long as there is a community back porting bug fixes we will push patch releases for those versions of io.js.

When old versions of dependencies like V8 are no longer supported by their project io.js will take on the responsibility of maintenance to ensure continued long term support in io.js patch releases.

## Channels

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be worthwhile to include a one to two sentence definition of what a channel is in this context.

* Release - Stable production ready builds. Unique version numbers following semver.
* Canary - Nightly builds w/ V8 version in Chrome Canary + changes landing to io.js. No version designation.
* NG - "Next Generation." No version designation.

## NG (Next Generation)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This section needs more explaining in general I think. E.g., what kind of experiments will NG be used for; how will you install it; when will changes from it make it into release; when can we start expecting NG builds. Many of those answers will probably be "I don't know" but I think it'd be nice to say that to make clear the whole NG thing is kind of fuzzy right now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The things you're actually for explanations about are still up for debate :)

The main point here is that:

  • we are going to have a future version of the platform
  • it won't break the existing ecosystem
  • there is a place for you to contribute to that effort
  • this work will not interfere with block or be blocked by the ongoing releases that are shipping improvements to the existing platform.


In order for io.js to stay competitive we need to work on the next generation of the platform that can more accurately integrate and reflect the advancements in the language and the ecosystem.

While this constitutes a great leap forward for the platform we will be making this leap without breaking backwards compatibility with the existing ecosystem of modules.

NG will use ES6 modules and will be implementing a new platform and standard library available only to modules using this native new style. Modules written prior to NG using the old CommonJS module syntax will continue to operate against the old API. This is what will allow us to make improvements to the platform without breaking compatibility and still letting future NG based applications benefit from all the modules built today.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment got blown away by an unrelated change. Reposting it because I'd like it to be more generally visible, sorry for the double post:

The NG proposal seems overreaching to me:

What do we need to experiment with regarding ES2015 primitives that would require putting a ES2015-module-syntax wall around them? There's a happy path for promises and the callback api to co-exist, so promise support shouldn't need to be walled as it can be purely additive. Streams are so invasive that changing that base primitive means we need to rewrite all of the stream-exposing APIs in node, which leads to use having two separate systems to maintain, a result I'm not fond of.

Why prompts the need to state a NG? Could we say something like "we will experiment with adding support ES2015 features behind feature flags, unflagging them as we're confident they are production-ready," followed by a list of the ES2015/WHATWG features we're actively looking at supporting (promises, whatwg/stream compat, etc)? Using the new module syntax as a gating method seems like an attractive idea, but I'm not sure we need to use it in order to build a better platform.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Notice that I removed reference to NG as having builds.

NG is here to do a couple things:

  1. Commit to doing a next generation version of the platform more in line with where JavaScript is in a year or so than where it was 6 years ago.
  2. Identify the mechanism (native ES6 modules) by which we can release this platform in the future without breaking any of the existing ecosytem.
  3. Give people a contribution endpoint where they can work on it.
    • This means work on future tech won't block continued stable releases.
    • This means continued stable releases won't block work on future tech.

The rest of your comments are all things that should be up for debate and iteration and if there are any places where it seems like we're committing to doing one thing or another let me know so that we can remove them ;)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Identify the mechanism (native ES6 modules) by which we can release this platform in the future without breaking any of the existing ecosytem.

Do we need to identify the mechanism in this roadmap? I'm not sold on the idea of using ES0xF module syntax to gate new functionality this way:

  • It's unclear when we start encouraging folks to make use of these features (shades of python3).
  • I'm not sure how much code would reasonably be shared between io.js OG and NG, so it feels like a second system.
  • I'm not sure that for the most interesting ES0xF changes, like adopting promises / async+await / generators, that those APIs could not live alongside or otherwise get brundle-fly'ed into our existing APIs. AFAIK things like typedarrays still have specific requirements that don't meet our needs for performance reasons. Is NG about ES0xF features, or about revisiting JS APIs? If it's about the latter, I'm not sure that there are really compelling reasons to commit to this specific mechanism up-front.

My preference here is to avoid committing to a far-reaching mechanism like module-syntax-gating until it becomes clear that feature flags alone aren't sufficient to get us to where we want to be.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without a delivery mechanism we do little to alleviate peoples compatibility fears or convince people working on NG that their code will ship.

However, this roadmap is a living document and is editable. Are we fine with saying the current plan for delivery is by use of new module syntax but if we have a better idea of course we're going to change it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If possible I'd like to go the --es-staging route and introduce an --iojs-staging flag (and corresponding IOJS_STAGING=1 env flag, for folks who use shebangs), that we can start landing promisifying PRs behind that – assuming that in either case we need to build this support out in io.js before we start accepting PRs / having people work on NG.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Admittedly a flag functions a lot less well as a metaphorical place for folks to do work / combine efforts than a separate set of modules; I understand the desire to have a location for folks to do the work of iterating on the API, but maybe that looks like an ng-wg issue/discussion repo instead of files within the repo?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little confused here. Are you saying that these flags will change the default platform or simply enable a new additive platform (available when using new module syntax)? I don't see how the current proposal excludes this.

The flags enable "next generation" features in the existing platform – for instance, returning promises from async APIs that are called sans callbacks, exposing the new module syntax, or experimental changes to streams.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@chrisdickinson right, this will probably begin with just a WG repo and some issue threads. It could be that the platform can be built using a compile-to toolchain and doesn't even need to live in core until it is much farther along, that's why I don't want to get stuck on it being a build or a branch yet.

Once we have some tacit agreement about the roadmap I'll create the repo and kick off a few issues.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The feature flags don't imply the existence or necessity of a new set of modules at the outset. We can reserve module-syntax-gating for the future if we determine that it's absolutely necessary, but this lets us iterate until we get to that point. We may find that we don't need to start exposing a new platform.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The flags enable "next generation" features in the existing platform – for instance, returning promises from async APIs that are called sans callbacks, exposing the new module syntax, or experimental changes to streams.

Extending the current API should be considered for regular releases and not block on theoretical future tech. I agree with the statement you've just made, I just don't see it as being under the same umbrella.

But, the reason I doubt we'll see something like that land is because it's such a drastic change for a fairly small gain in terms of the overall platform being friendly to new patterns. Doesn't mean we shouldn't try it out behind a flag though, especially since it's a good way to flush out issues we know we have with native promises (like we can't do AsyncWrap yet).


# Immediate Priorities

## Debugging and Tracing

Debugging is one of the first things from everyone's mouth, both developer and enterprise, when describing trouble they've had with node.js/io.js.

The goal of io.js' effort 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](https://github.com/iojs/tracing-wg) is driving this effort:

* 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 tracing support for more platforms (LTTng, etc).
* [Unify the Tracing endpoint](https://github.com/iojs/io.js/issues/729).
* 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 requires new automation.

The initial goals for this automation are relatively simple but will create a baseline toolchain we can continue to improve upon.

* Produce a list of modules that no longer build between two release versions.
* Produce a list of modules that use a particular core API.
* Produce detailed code coverage data for the tests in core.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a link to an issue or repo representing this work for those who would like to get involved?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not yet, but I'll add one once there is :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rad, I'd love to get in on this. I've built a few silly little tools for CFG/AST analysis and it'd be great to put 'em to use :)


## Improve Installation and Upgrades

* Host and maintain registry endpoints (Homebrew, apt, etc).
* Document installation and upgrade procedures with an emphasis on using nvm or nave for development and our registry endpoints for traditional package managers and production.

## Streams

* Fix all existing compatibility issues.
* Simplify stream creation to avoid user error.
* Explore and identify compatibility issues with [WHATWG Streams](https://github.com/whatwg/streams).
* Improve stream performance.

## Internationalization / Localization

* Build documentation tooling with localization support built in.
* Reduce size of ICU and ship with it by default.
* Continue growth of our i18n community.