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.

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

Roadmap #886

Closed
wants to merge 8 commits into
base: v1.x
from

Conversation

Projects
None yet
7 participants
@mikeal
Member

mikeal commented Feb 19, 2015

The culmination of a lot of work in various issues and PRs.

Let the bikeshedding begin.

PS. @chrisdickinson will surely comment that we really need to find a place to put these documents that isn't just in the root of the project and I agree but until we have such a place I'll continue to post them like this :P

This was referenced Feb 19, 2015

Show outdated Hide outdated ROADMAP.md
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 maintinence to ensure continued long term support in `io.js` patch releases.

This comment has been minimized.

@ruimarinho

ruimarinho Feb 19, 2015

Member

Typo on maintinence.

@ruimarinho

ruimarinho Feb 19, 2015

Member

Typo on maintinence.

Show outdated Hide outdated ROADMAP.md
The single more 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 JavaScript API.

This comment has been minimized.

@ruimarinho

ruimarinho Feb 19, 2015

Member

I would clarify this a bit. By JS API, do you mean "EcmaScript" API or node core API?

@ruimarinho

ruimarinho Feb 19, 2015

Member

I would clarify this a bit. By JS API, do you mean "EcmaScript" API or node core API?

This comment has been minimized.

@dshaw

dshaw Feb 19, 2015

Member

There are two points to consider here. I believe the intent is that "io.js does not remove JavaScript API from core". Beyond that, there's the interesting challenge that might occur dealing with volatile changes in V8 such as the broken Promises and Classes that shipped at one point.

@dshaw

dshaw Feb 19, 2015

Member

There are two points to consider here. I believe the intent is that "io.js does not remove JavaScript API from core". Beyond that, there's the interesting challenge that might occur dealing with volatile changes in V8 such as the broken Promises and Classes that shipped at one point.

This comment has been minimized.

@ruimarinho

ruimarinho Feb 19, 2015

Member

@dshaw, fortunately that is really unlikely to happen again due to how stable releases of io.js will also track stable versions of V8, which is a guarantee io.js will never "unship" shipped V8 features.

@ruimarinho

ruimarinho Feb 19, 2015

Member

@dshaw, fortunately that is really unlikely to happen again due to how stable releases of io.js will also track stable versions of V8, which is a guarantee io.js will never "unship" shipped V8 features.

Show outdated Hide outdated ROADMAP.md
io.js does not remove JavaScript 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 maintinence as part of our Long Term Support policy.

This comment has been minimized.

@ruimarinho

ruimarinho Feb 19, 2015

Member

Typo on maintinence.

@ruimarinho

ruimarinho Feb 19, 2015

Member

Typo on maintinence.

This comment has been minimized.

@ruimarinho

ruimarinho Feb 19, 2015

Member

Possibly crosslink term Long Term Supported to the section below.

@ruimarinho

ruimarinho Feb 19, 2015

Member

Possibly crosslink term Long Term Supported to the section below.

Show outdated Hide outdated ROADMAP.md
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 maintinence as part of our Long Term Support policy.
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`

This comment has been minimized.

@ruimarinho

ruimarinho Feb 19, 2015

Member

v8 should be written as V8 instead.

@ruimarinho

ruimarinho Feb 19, 2015

Member

v8 should be written as V8 instead.

This comment has been minimized.

@ruimarinho

ruimarinho Feb 19, 2015

Member

I'd crosslink nan with the github repo.

@ruimarinho

ruimarinho Feb 19, 2015

Member

I'd crosslink nan with the github repo.

Show outdated Hide outdated ROADMAP.md
## NG (Next Generation)
> This is not Python 3!

This comment has been minimized.

@ruimarinho

ruimarinho Feb 19, 2015

Member

I would remove this reference :P you never know haha.

@ruimarinho

ruimarinho Feb 19, 2015

Member

I would remove this reference :P you never know haha.

This comment has been minimized.

@piscisaureus

piscisaureus Feb 19, 2015

Member

+1 on removing

@piscisaureus

piscisaureus Feb 19, 2015

Member

+1 on removing

Show outdated Hide outdated ROADMAP.md
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 in 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 compatiblity and still letting future NG based applications benefit from all the modules built today.

This comment has been minimized.

@ruimarinho

ruimarinho Feb 19, 2015

Member

NG using in the old CommonJS -> NG using the old CommonJS

@ruimarinho

ruimarinho Feb 19, 2015

Member

NG using in the old CommonJS -> NG using the old CommonJS

This comment has been minimized.

@ruimarinho

ruimarinho Feb 19, 2015

Member

compatiblity -> compatibility

@ruimarinho

ruimarinho Feb 19, 2015

Member

compatiblity -> compatibility

Show outdated Hide outdated ROADMAP.md
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.

This comment has been minimized.

@ruimarinho

ruimarinho Feb 19, 2015

Member

I'd replace -- by .

@ruimarinho

ruimarinho Feb 19, 2015

Member

I'd replace -- by .

Show outdated Hide outdated ROADMAP.md
* 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.

This comment has been minimized.

@ruimarinho

ruimarinho Feb 19, 2015

Member

Can you share any reference on this? I'd like to learn about it.

@ruimarinho

ruimarinho Feb 19, 2015

Member

Can you share any reference on this? I'd like to learn about it.

Show outdated Hide outdated ROADMAP.md
## Streams
* Fix all existing compatibility issues.
* Simplify stream usage and creation to avoid user error.

This comment has been minimized.

@ruimarinho

ruimarinho Feb 19, 2015

Member

I'd switch the creation and usage word order.

@ruimarinho

ruimarinho Feb 19, 2015

Member

I'd switch the creation and usage word order.

Show outdated Hide outdated ROADMAP.md
* Implement WHATWG Streams interface and identify compatibility issues.
* Improve stream performance.
## Localization

This comment has been minimized.

@ruimarinho

ruimarinho Feb 19, 2015

Member

Sugg: ## Internationalization / Localization. More area for those quick ⌘+F :)

@ruimarinho

ruimarinho Feb 19, 2015

Member

Sugg: ## Internationalization / Localization. More area for those quick ⌘+F :)

@ruimarinho

This comment has been minimized.

Show comment
Hide comment
@ruimarinho

ruimarinho Feb 19, 2015

Member

Nice work! It feels really good to finally have the long term plans organized like this 👏

Member

ruimarinho commented Feb 19, 2015

Nice work! It feels really good to finally have the long term plans organized like this 👏

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Feb 19, 2015

Member

Just landed a ton of edits based on this early feedback.

Member

mikeal commented Feb 19, 2015

Just landed a ton of edits based on this early feedback.

Show outdated Hide outdated ROADMAP.md
### Long Term Support
`io.js` supports old versions for as long as community members are fixing bugs in them.

This comment has been minimized.

@domenic

domenic Feb 19, 2015

Member

Here you starting switching to code-ifying io.js instead of io.js.

@domenic

domenic Feb 19, 2015

Member

Here you starting switching to code-ifying io.js instead of io.js.

Show outdated Hide outdated ROADMAP.md
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.

This comment has been minimized.

@domenic

domenic Feb 19, 2015

Member

This isn't very clear. So the community back-ports io.js bug fixes, but the core team maintains a bunch of old V8 versions? How many does the core team maintain in parallel---one for every patch release of io.js ever?

@domenic

domenic Feb 19, 2015

Member

This isn't very clear. So the community back-ports io.js bug fixes, but the core team maintains a bunch of old V8 versions? How many does the core team maintain in parallel---one for every patch release of io.js ever?

This comment has been minimized.

@mikeal

mikeal Feb 19, 2015

Member

Sorry, there is no "core team" and "community" distinction here. There are people who care about LTS, they can contribute through backporting fixes, including fixes for older dependencies.

@mikeal

mikeal Feb 19, 2015

Member

Sorry, there is no "core team" and "community" distinction here. There are people who care about LTS, they can contribute through backporting fixes, including fixes for older dependencies.

This comment has been minimized.

@domenic

domenic Feb 19, 2015

Member

Even in the latest version this isn't very clear. There's a big difference between the first two paragraphs which are "as long as the community submits patches we will do releases" and the last one which is "io.js will take on the responsibility of maintenance for all old V8 releases that we bundle in our releases." It should be more clear that the latter is just a facet of the former. E.g. "the same process applies for dependencies. If, for example, the community wants to help backport security patches from later V8 versions to those shipped with old io.js releases, we will readily take them and float them onto the version of V8 found in the appropriate io.js branch."

@domenic

domenic Feb 19, 2015

Member

Even in the latest version this isn't very clear. There's a big difference between the first two paragraphs which are "as long as the community submits patches we will do releases" and the last one which is "io.js will take on the responsibility of maintenance for all old V8 releases that we bundle in our releases." It should be more clear that the latter is just a facet of the former. E.g. "the same process applies for dependencies. If, for example, the community wants to help backport security patches from later V8 versions to those shipped with old io.js releases, we will readily take them and float them onto the version of V8 found in the appropriate io.js branch."

Show outdated Hide outdated ROADMAP.md
## 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.

This comment has been minimized.

@domenic

domenic Feb 19, 2015

Member

"next-generation V8" is confusing with NG and imprecise.

Given e.g. the current situation at https://omahaproxy.appspot.com/, what V8 should we use? I'd vote on the one corresponding to Chrome dev (or maybe canary). That will generally be two Chrome versions ahead of where we are now (although as you know currently we're ahead of Chrome by one version for the next few weeks). Alternately we could try Chrome beta for less churn; that still gives a 6-week head start.

@domenic

domenic Feb 19, 2015

Member

"next-generation V8" is confusing with NG and imprecise.

Given e.g. the current situation at https://omahaproxy.appspot.com/, what V8 should we use? I'd vote on the one corresponding to Chrome dev (or maybe canary). That will generally be two Chrome versions ahead of where we are now (although as you know currently we're ahead of Chrome by one version for the next few weeks). Alternately we could try Chrome beta for less churn; that still gives a 6-week head start.

This comment has been minimized.

@chrisdickinson

chrisdickinson Feb 19, 2015

Contributor

Making canary === nightly doesn't give downstream folks confidence that any given nightly build is likely to represent the next stable version. It's a lot more work to keep up with something that is output daily, it might be wasted if the changes are backed out or changed the next day, and the only nightly that will accurately reflect the next stable release will drop the day before the stable release.

@chrisdickinson

chrisdickinson Feb 19, 2015

Contributor

Making canary === nightly doesn't give downstream folks confidence that any given nightly build is likely to represent the next stable version. It's a lot more work to keep up with something that is output daily, it might be wasted if the changes are backed out or changed the next day, and the only nightly that will accurately reflect the next stable release will drop the day before the stable release.

This comment has been minimized.

@mikeal

mikeal Feb 19, 2015

Member

For now I think we should go with Canary. We just had Tracing WG cal and there is a bunch of stuff going in soon that we'll want to start working with immediately. Until that is no longer the case we should have our Canary channel use the v8 in Chrome Canary.

@mikeal

mikeal Feb 19, 2015

Member

For now I think we should go with Canary. We just had Tracing WG cal and there is a bunch of stuff going in soon that we'll want to start working with immediately. Until that is no longer the case we should have our Canary channel use the v8 in Chrome Canary.

This comment has been minimized.

@domenic

domenic Feb 19, 2015

Member

My understanding of Dev is that it's basically Canary but with a bit more testing. It updates once or twice weekly. http://www.chromium.org/getting-involved/dev-channel So it might also be a reasonable choice. Unless we plan on having an automated way to roll in new V8 versions.

@domenic

domenic Feb 19, 2015

Member

My understanding of Dev is that it's basically Canary but with a bit more testing. It updates once or twice weekly. http://www.chromium.org/getting-involved/dev-channel So it might also be a reasonable choice. Unless we plan on having an automated way to roll in new V8 versions.

Show outdated Hide outdated ROADMAP.md
* Canary - Nightly builds on next-generation V8 + changes landing to io.js. No version designation.
* NG - "Next Generation." No version designation.
## NG (Next Generation)

This comment has been minimized.

@domenic

domenic Feb 19, 2015

Member

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.

@domenic

domenic Feb 19, 2015

Member

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.

This comment has been minimized.

@mikeal

mikeal Feb 19, 2015

Member

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.
@mikeal

mikeal Feb 19, 2015

Member

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.
@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Feb 19, 2015

Member

It might be interesting to say something like "io.js has the benefit of learning from the past experience of many other platforms and languages, and will not repeat their mistakes by abandoning compatibility with existing code while building next-generation solutions. Instead, we plan to work on a system that allows next-generation evolutions of the core libraries to live alongside and interoperate with the existing versions." Then talk about ES2015 modules or versioned core modules you install from npm or similar.

Member

domenic commented on ROADMAP.md in 5304e8d Feb 19, 2015

It might be interesting to say something like "io.js has the benefit of learning from the past experience of many other platforms and languages, and will not repeat their mistakes by abandoning compatibility with existing code while building next-generation solutions. Instead, we plan to work on a system that allows next-generation evolutions of the core libraries to live alongside and interoperate with the existing versions." Then talk about ES2015 modules or versioned core modules you install from npm or similar.

Show outdated Hide outdated ROADMAP.md
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.

This comment has been minimized.

@chrisdickinson

chrisdickinson Feb 19, 2015

Contributor

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.

@chrisdickinson

chrisdickinson Feb 19, 2015

Contributor

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.

This comment has been minimized.

@mikeal

mikeal Feb 19, 2015

Member

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 ;)

@mikeal

mikeal Feb 19, 2015

Member

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 ;)

This comment has been minimized.

@chrisdickinson

chrisdickinson Feb 19, 2015

Contributor

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.

@chrisdickinson

chrisdickinson Feb 19, 2015

Contributor

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.

This comment has been minimized.

@mikeal

mikeal Feb 19, 2015

Member

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?

@mikeal

mikeal Feb 19, 2015

Member

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?

This comment has been minimized.

@chrisdickinson

chrisdickinson Feb 20, 2015

Contributor

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.

@chrisdickinson

chrisdickinson Feb 20, 2015

Contributor

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.

This comment has been minimized.

@chrisdickinson

chrisdickinson Feb 20, 2015

Contributor

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?

@chrisdickinson

chrisdickinson Feb 20, 2015

Contributor

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?

This comment has been minimized.

@chrisdickinson

chrisdickinson Feb 20, 2015

Contributor

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.

@chrisdickinson

chrisdickinson Feb 20, 2015

Contributor

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.

This comment has been minimized.

@mikeal

mikeal Feb 20, 2015

Member

@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.

@mikeal

mikeal Feb 20, 2015

Member

@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.

This comment has been minimized.

@chrisdickinson

chrisdickinson Feb 20, 2015

Contributor

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.

@chrisdickinson

chrisdickinson Feb 20, 2015

Contributor

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.

This comment has been minimized.

@mikeal

mikeal Feb 20, 2015

Member

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).

@mikeal

mikeal Feb 20, 2015

Member

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).

Show outdated Hide outdated ROADMAP.md
* Fix all existing compatibility issues.
* Simplify stream creation to avoid user error.
* Implement WHATWG Streams interface and identify compatibility issues.

This comment has been minimized.

@chrisdickinson

chrisdickinson Feb 19, 2015

Contributor

We might say "explore compatibility with WHATWG Streams", we may never implement WHATWG streams exactly. May also be worth linking "WHATWG Streams" to the github repo.

@chrisdickinson

chrisdickinson Feb 19, 2015

Contributor

We might say "explore compatibility with WHATWG Streams", we may never implement WHATWG streams exactly. May also be worth linking "WHATWG Streams" to the github repo.

This comment has been minimized.

@mikeal

mikeal Feb 19, 2015

Member

Well, someone should implement a reverse compatible version of WHATWG streams but that shouldn't necessarily be readable-stream. I'll modify to the language here.

@mikeal

mikeal Feb 19, 2015

Member

Well, someone should implement a reverse compatible version of WHATWG streams but that shouldn't necessarily be readable-stream. I'll modify to the language here.

* 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.

This comment has been minimized.

@chrisdickinson

chrisdickinson Feb 19, 2015

Contributor

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

@chrisdickinson

chrisdickinson Feb 19, 2015

Contributor

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

This comment has been minimized.

@mikeal

mikeal Feb 19, 2015

Member

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

@mikeal

mikeal Feb 19, 2015

Member

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

This comment has been minimized.

@chrisdickinson

chrisdickinson Feb 19, 2015

Contributor

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 :)

@chrisdickinson

chrisdickinson Feb 19, 2015

Contributor

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 :)

Show outdated Hide outdated ROADMAP.md
## Stability Policy
The single more important consideration in every code change is the impact it will have, positive or negative, on the ecosystem (modules and applications).

This comment has been minimized.

@chrisdickinson

chrisdickinson Feb 19, 2015

Contributor

s/more /most / – I might drop single as well, since most implies singularity.

@chrisdickinson

chrisdickinson Feb 19, 2015

Contributor

s/more /most / – I might drop single as well, since most implies singularity.

This comment has been minimized.

@mikeal

mikeal Feb 19, 2015

Member

Good call, updating.

@mikeal

mikeal Feb 19, 2015

Member

Good call, updating.

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

This comment has been minimized.

@chrisdickinson

chrisdickinson Feb 19, 2015

Contributor

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

@chrisdickinson

chrisdickinson Feb 19, 2015

Contributor

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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 20, 2015

I disagree with what @sam-github said in issue #725 because that would mean breaking applications so what I would propose is give APIs that are broken/mistaken a special prefix so you can make a better version while still maintaining applications that require the old feature.

ghost commented Feb 20, 2015

I disagree with what @sam-github said in issue #725 because that would mean breaking applications so what I would propose is give APIs that are broken/mistaken a special prefix so you can make a better version while still maintaining applications that require the old feature.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Feb 20, 2015

Member

@chrisdickinson I made some adjustments and deletions based on your feedback.

Member

mikeal commented Feb 20, 2015

@chrisdickinson I made some adjustments and deletions based on your feedback.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Feb 21, 2015

Member

I think all the feedback has been addressed. I think is ready to merge unless there are any objections?

Member

mikeal commented Feb 21, 2015

I think all the feedback has been addressed. I think is ready to merge unless there are any objections?

@chrisdickinson

This comment has been minimized.

Show comment
Hide comment
@chrisdickinson

chrisdickinson Feb 21, 2015

Contributor

This LGTM. Nice work!

Contributor

chrisdickinson commented Feb 21, 2015

This LGTM. Nice work!

@sam-github

This comment has been minimized.

Show comment
Hide comment
@sam-github

sam-github Feb 23, 2015

Member

@BenjaminProgram re: #886 (comment)

Giving APIs we wish never existed a special prefix has a number of issues, beyond the awful cosmetics:

  • it still breaks any existing app that uses the feature, they have to change the code, so why not just use the new better API?
  • it doesn't work for behavioural changes (like client dgram sockets not being cluster distributed, or changing how cluster's worker.kill() works)
  • it doesn't work when the goal is to remote the mistaken feature, like the domains code that was shotgunned into node, making node as a whole more complex
Member

sam-github commented Feb 23, 2015

@BenjaminProgram re: #886 (comment)

Giving APIs we wish never existed a special prefix has a number of issues, beyond the awful cosmetics:

  • it still breaks any existing app that uses the feature, they have to change the code, so why not just use the new better API?
  • it doesn't work for behavioural changes (like client dgram sockets not being cluster distributed, or changing how cluster's worker.kill() works)
  • it doesn't work when the goal is to remote the mistaken feature, like the domains code that was shotgunned into node, making node as a whole more complex
@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 24, 2015

@sam-github Because sometime the app is not compatible with the better API, and it is easier to change the API name in code than to rewrite the code. But, I do see your points.

ghost commented Feb 24, 2015

@sam-github Because sometime the app is not compatible with the better API, and it is easier to change the API name in code than to rewrite the code. But, I do see your points.

mikeal added a commit that referenced this pull request Feb 26, 2015

doc: document roadmap, workgroups
PR: #886
Reviewed-By: Chris Dickinson <christopher.s.dickinson@gmail.com>
Reviewed-by: Bert Belder <bertbelder@gmail.com>
@piscisaureus

This comment has been minimized.

Show comment
Hide comment
@piscisaureus

piscisaureus Feb 26, 2015

Member

Thanks Mikeal! Landed in 14174a9.

Member

piscisaureus commented Feb 26, 2015

Thanks Mikeal! Landed in 14174a9.

@rvagg rvagg deleted the roadmap branch Oct 28, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment