Initial Release #28

Closed
mikeal opened this Issue Dec 2, 2014 · 97 comments

Comments

Projects
None yet
@mikeal
Member

mikeal commented Dec 2, 2014

In the TC meeting today we came up with a vision for the first release.

First, a few assumptions we've internalized that probably need to be stated for this to make sense.

  • Node is pretty damn stable already. There are huge companies with it in production, 100K+ modules, etc. It is already far more stable that its pre-1.0 release tag suggests.
  • Releasing more frequently leads to a more stable product, not a less stable product.
  • The entire ecosystem uses semver while node uses a confusing even/odd release structure.

If people disagree with any of those assumptions then they certainly won't agree with anything the TC determined for the initial release.

So, first release of io.js:

  • January 13th (Fedor's Birthday!) target date.
  • Will be 1.0-alpha1, with alpha releases continuing until 1.0.0.
  • Switching to semver.
  • We will be taking new v8 releases as fast as possible moving forward.
  • Trying to get to a weekly release cycle. Which version number is incremented each week is determined by the changes and whether or not they are breaking. Again, following semver.

Some questions still left open:

  • Are there any changes other than dep upgrades and fixes required for 1.0?
  • Is build confident we can have enough automation in place to hit this date.
  • Is the plan to have the installer install an iojs binary and an alias to node?
@SomeoneWeird

This comment has been minimized.

Show comment
Hide comment
@SomeoneWeird

SomeoneWeird Dec 2, 2014

Member
We will be taking new v8 releases as fast as possible moving forward.

Absolutely +1.

Is the plan to have the installer install an iojs binary and an alias to node?

I think this should work, but it should check if node is already installed and not alias if it is.

Member

SomeoneWeird commented Dec 2, 2014

We will be taking new v8 releases as fast as possible moving forward.

Absolutely +1.

Is the plan to have the installer install an iojs binary and an alias to node?

I think this should work, but it should check if node is already installed and not alias if it is.

@creationix

This comment has been minimized.

Show comment
Hide comment
@creationix

creationix Dec 2, 2014

Contributor

I have a concern and a question.

First to me it seems that weekly is too often. I understand you're trying to balance the insanely slow pace of recent node development, but don't flip to the other extreme. How much effort is it to cut a release? I know for me a luvi release takes a couple hours, iojs is a bit more involved, but also has a lot more supporting scripts.

Second, I love the idea of pulling in V8 changes as fast as possible. What ever happened to the idea to create a new C API layer that shields addon authors from V8 API changes? I could offer some help here but I thought Trevor has some ideas here and was farther along. Would this need to get in before a 1.0.0 release or could it just be a 1.1.x thing or 2.0.x thing?

Contributor

creationix commented Dec 2, 2014

I have a concern and a question.

First to me it seems that weekly is too often. I understand you're trying to balance the insanely slow pace of recent node development, but don't flip to the other extreme. How much effort is it to cut a release? I know for me a luvi release takes a couple hours, iojs is a bit more involved, but also has a lot more supporting scripts.

Second, I love the idea of pulling in V8 changes as fast as possible. What ever happened to the idea to create a new C API layer that shields addon authors from V8 API changes? I could offer some help here but I thought Trevor has some ideas here and was farther along. Would this need to get in before a 1.0.0 release or could it just be a 1.1.x thing or 2.0.x thing?

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Dec 2, 2014

Member

Will be 1.0-alpha1, with alpha releases continuing until 1.0.0.

I am curious what differentiates 1.0.0-alpha.1 from 1.0.0? Perhaps that is your

Are there any changes other than dep upgrades and fixes required for 1.0?

I am leery of a long series of alpha/beta/gamma releases before a true, semver-ful 1.0.0 is released. All in all I would prefer a 1.0.0 release as the initial release---unless the TC anticipates actually making breaking changes in the subsequent releases.

Member

domenic commented Dec 2, 2014

Will be 1.0-alpha1, with alpha releases continuing until 1.0.0.

I am curious what differentiates 1.0.0-alpha.1 from 1.0.0? Perhaps that is your

Are there any changes other than dep upgrades and fixes required for 1.0?

I am leery of a long series of alpha/beta/gamma releases before a true, semver-ful 1.0.0 is released. All in all I would prefer a 1.0.0 release as the initial release---unless the TC anticipates actually making breaking changes in the subsequent releases.

@indutny

This comment has been minimized.

Show comment
Hide comment
@indutny

indutny Dec 2, 2014

Member

@creationix the idea with shielding C API was rejected. V8 should stay more stable in next versions, as they have finished their major API migration.

Member

indutny commented Dec 2, 2014

@creationix the idea with shielding C API was rejected. V8 should stay more stable in next versions, as they have finished their major API migration.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Dec 2, 2014

Member

How much effort is it to cut a release?

The goal is zero and that everything is entirely automated. Without that I don't think weekly releases are practical at all.

Member

mikeal commented Dec 2, 2014

How much effort is it to cut a release?

The goal is zero and that everything is entirely automated. Without that I don't think weekly releases are practical at all.

@cjihrig

This comment has been minimized.

Show comment
Hide comment
@cjihrig

cjihrig Dec 2, 2014

Contributor

Wasn't nan at least partially blessed in node-forward for shielding addon developers as well?

Contributor

cjihrig commented Dec 2, 2014

Wasn't nan at least partially blessed in node-forward for shielding addon developers as well?

@chrisdickinson

This comment has been minimized.

Show comment
Hide comment
@chrisdickinson

chrisdickinson Dec 2, 2014

Contributor

If people disagree with any of those assumptions then they certainly won't agree with anything the TC determined for the initial release.

Curious: what does this mean for changing core primitives, like streams, going forward? Are they effectively locked now?

Other questions / concerns:

  • How many prior major versions will be supported by core?
  • How much lead time will the community have before a new major version drops? Is it possible to move towards a canary release system where one week's release is last week's canary, so we give folks who are instrumenting Node (cough cough @wraithan) enough time to adapt?
Contributor

chrisdickinson commented Dec 2, 2014

If people disagree with any of those assumptions then they certainly won't agree with anything the TC determined for the initial release.

Curious: what does this mean for changing core primitives, like streams, going forward? Are they effectively locked now?

Other questions / concerns:

  • How many prior major versions will be supported by core?
  • How much lead time will the community have before a new major version drops? Is it possible to move towards a canary release system where one week's release is last week's canary, so we give folks who are instrumenting Node (cough cough @wraithan) enough time to adapt?
@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Dec 2, 2014

Member

@domenic I would be cautious about a brand new build, release and test system. I'd like to put out some alphas that people can use just to shake out any bugs and build confidence before we stamp something 1.0.

Member

mikeal commented Dec 2, 2014

@domenic I would be cautious about a brand new build, release and test system. I'd like to put out some alphas that people can use just to shake out any bugs and build confidence before we stamp something 1.0.

@espadrine

This comment has been minimized.

Show comment
Hide comment
@espadrine

espadrine Dec 2, 2014

I wonder what the plan is regarding the adoption of ES6 features. Specifically, modules and promises. iojs currently has competing technologies, and it could potentially transition. Would that trigger a major version increment, and therefore, be the 2.0.0 version?

I wonder what the plan is regarding the adoption of ES6 features. Specifically, modules and promises. iojs currently has competing technologies, and it could potentially transition. Would that trigger a major version increment, and therefore, be the 2.0.0 version?

@ghostbar

This comment has been minimized.

Show comment
Hide comment
@ghostbar

ghostbar Dec 2, 2014

Contributor

@mikeal agreed, I think the -alpha makes sense for watching out for new bugs, even a -rc0,1,2,3...

Contributor

ghostbar commented Dec 2, 2014

@mikeal agreed, I think the -alpha makes sense for watching out for new bugs, even a -rc0,1,2,3...

@therebelrobot

This comment has been minimized.

Show comment
Hide comment
Member

therebelrobot commented Dec 2, 2014

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Dec 2, 2014

Member

@chrisdickinson well... the last few changes to streams required full backward compatibility (or at least what we thought was fully compatible) because of the mountain of existing dependencies. I would expect additional changes to run through the same gamut, although with semver we do have a way to signal that a compatibility break is happening, but there is still going to be a big cost benefit analysis on breaking something so depended upon.

that said, you could see a future where moving toward or being more compatible with the upcoming streams work @domenic is doing as being the kind of benefit that might push a breaking change over the edge.

Member

mikeal commented Dec 2, 2014

@chrisdickinson well... the last few changes to streams required full backward compatibility (or at least what we thought was fully compatible) because of the mountain of existing dependencies. I would expect additional changes to run through the same gamut, although with semver we do have a way to signal that a compatibility break is happening, but there is still going to be a big cost benefit analysis on breaking something so depended upon.

that said, you could see a future where moving toward or being more compatible with the upcoming streams work @domenic is doing as being the kind of benefit that might push a breaking change over the edge.

@basicallydan

This comment has been minimized.

Show comment
Hide comment
@basicallydan

basicallydan Dec 2, 2014

I think an alias to node would be useful but not by default. An uneducated user who doesn't know about the relationship between iojs and Node might not be expecting it.

I think an alias to node would be useful but not by default. An uneducated user who doesn't know about the relationship between iojs and Node might not be expecting it.

@creationix

This comment has been minimized.

Show comment
Hide comment
@creationix

creationix Dec 2, 2014

Contributor

Regarding the locked primitives. I highly recommending splitting the code into core and sugar like I did for luvit. The luv module is just libuv bindings for lua. We could have just libuv bindings for v8. Then the luvi project is luajit + luv + openssl + other C libraries, but zero API sugar. Very C-like APIs. This would be the mythical no.js project. Then luvit is the full node.js style APIs with node streams, event emitters, etc all implemented in pure lua on top of luvi. That's the equivalent to node.js/iojs level of abstraction.

I know this is harder for node because of how optimization was done mixing the lines between bindings and sugar, but I still think it's the only viable future to preserve the current APIs that everyone uses and enable a clean way to explore other styles while still reusing the C core of node.

Contributor

creationix commented Dec 2, 2014

Regarding the locked primitives. I highly recommending splitting the code into core and sugar like I did for luvit. The luv module is just libuv bindings for lua. We could have just libuv bindings for v8. Then the luvi project is luajit + luv + openssl + other C libraries, but zero API sugar. Very C-like APIs. This would be the mythical no.js project. Then luvit is the full node.js style APIs with node streams, event emitters, etc all implemented in pure lua on top of luvi. That's the equivalent to node.js/iojs level of abstraction.

I know this is harder for node because of how optimization was done mixing the lines between bindings and sugar, but I still think it's the only viable future to preserve the current APIs that everyone uses and enable a clean way to explore other styles while still reusing the C core of node.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Dec 2, 2014

Member

How many prior major versions will be supported by core?

This is going to end up depending on the level of adoption in each version and how many contributors we end up bring on board. It's not something we should commit to now except to say that "until we say we're deprecating support of a release all releases are supported."

How much lead time will the community have before a new major version drops? Is it possible to move towards a canary release system where one week's release is last week's canary, so we give folks who are instrumenting Node (cough cough @wraithan) enough time to adapt?

We want nightly builds, and this weekly swap is probably also a good idea.

Member

mikeal commented Dec 2, 2014

How many prior major versions will be supported by core?

This is going to end up depending on the level of adoption in each version and how many contributors we end up bring on board. It's not something we should commit to now except to say that "until we say we're deprecating support of a release all releases are supported."

How much lead time will the community have before a new major version drops? Is it possible to move towards a canary release system where one week's release is last week's canary, so we give folks who are instrumenting Node (cough cough @wraithan) enough time to adapt?

We want nightly builds, and this weekly swap is probably also a good idea.

@a0viedo

This comment has been minimized.

Show comment
Hide comment
@a0viedo

a0viedo Dec 2, 2014

Member

Switching to semver.

👏

Is the plan to have the installer install an iojs binary and an alias to node?

I'm with @SomeoneWeird, it should not make the alias if node is already installed.

Member

a0viedo commented Dec 2, 2014

Switching to semver.

👏

Is the plan to have the installer install an iojs binary and an alias to node?

I'm with @SomeoneWeird, it should not make the alias if node is already installed.

@indutny

This comment has been minimized.

Show comment
Hide comment
@indutny

indutny Dec 2, 2014

Member

@cjihrig it is, gosh! I always forget about it :) please do not take it as offense.

Member

indutny commented Dec 2, 2014

@cjihrig it is, gosh! I always forget about it :) please do not take it as offense.

@sintaxi

This comment has been minimized.

Show comment
Hide comment
@sintaxi

sintaxi Dec 2, 2014

Looks like a solid plan. One question, will v1 be based on node 0.10.x or 0.11.x?

sintaxi commented Dec 2, 2014

Looks like a solid plan. One question, will v1 be based on node 0.10.x or 0.11.x?

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Dec 2, 2014

Member

@sintaxi the 0.12 branch here.

Member

mikeal commented Dec 2, 2014

@sintaxi the 0.12 branch here.

@sintaxi

This comment has been minimized.

Show comment
Hide comment
@sintaxi

sintaxi Dec 2, 2014

@mikeal sounds good. thanks.

sintaxi commented Dec 2, 2014

@mikeal sounds good. thanks.

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Dec 2, 2014

Member

@domenic I would be cautious about a brand new build, release and test system. I'd like to put out some alphas that people can use just to shake out any bugs and build confidence before we stamp something 1.0.

That makes sense. Would just like to suggest making some sort of explicit commitment that the goal is to get a 1.0.0 out within a few releases or some time period. Maybe revisit the details of the commitment when 1.0.0-alpha.1 lands so you can take stock of what people think of the release.

All I'm saying is that as-is, the only stated goal is 1.0.0-alpha.1, with no thought toward a real 1.0.0, which makes me nervous that we'll end up like Ember and play around in the alpha/beta stage for half a year (similar to 0.12 being stuck in the 0.11 stage for ... well, forever).

Member

domenic commented Dec 2, 2014

@domenic I would be cautious about a brand new build, release and test system. I'd like to put out some alphas that people can use just to shake out any bugs and build confidence before we stamp something 1.0.

That makes sense. Would just like to suggest making some sort of explicit commitment that the goal is to get a 1.0.0 out within a few releases or some time period. Maybe revisit the details of the commitment when 1.0.0-alpha.1 lands so you can take stock of what people think of the release.

All I'm saying is that as-is, the only stated goal is 1.0.0-alpha.1, with no thought toward a real 1.0.0, which makes me nervous that we'll end up like Ember and play around in the alpha/beta stage for half a year (similar to 0.12 being stuck in the 0.11 stage for ... well, forever).

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Dec 2, 2014

Member

@domenic all good points, I guess we should probably state that "no features will be added between 1.0-a1 and 1.0"

Member

mikeal commented Dec 2, 2014

@domenic all good points, I guess we should probably state that "no features will be added between 1.0-a1 and 1.0"

@kenperkins

This comment has been minimized.

Show comment
Hide comment
@kenperkins

kenperkins Dec 2, 2014

Contributor

How about:

The goal of not immediately releasing v1.0.0 is to provide a buffer between v1.0.0-alpha1 and v1.0.0 to allow the build process to mature.

Contributor

kenperkins commented Dec 2, 2014

How about:

The goal of not immediately releasing v1.0.0 is to provide a buffer between v1.0.0-alpha1 and v1.0.0 to allow the build process to mature.

@sergi

This comment has been minimized.

Show comment
Hide comment

sergi commented Dec 2, 2014

👍

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Dec 2, 2014

Member

@kenperkins perfect :)

Member

mikeal commented Dec 2, 2014

@kenperkins perfect :)

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Dec 2, 2014

Member

I think this should work, but it should check if node is already installed and not alias if it is.

The problem with this is that the installer also installs npm which is going to link to a different node than the one accessible by node if already installed. Apparently, package managers have a way to mark a package as "conflicting" with another. We can use this to ensure proper warnings when installing iojs where nodejs may have already been installed.

Member

mikeal commented Dec 2, 2014

I think this should work, but it should check if node is already installed and not alias if it is.

The problem with this is that the installer also installs npm which is going to link to a different node than the one accessible by node if already installed. Apparently, package managers have a way to mark a package as "conflicting" with another. We can use this to ensure proper warnings when installing iojs where nodejs may have already been installed.

@SomeoneWeird

This comment has been minimized.

Show comment
Hide comment
@SomeoneWeird

SomeoneWeird Dec 2, 2014

Member
Apparently, package managers have a way to mark a package as "conflicting" with another.

For sure, I guess it just makes testing/migrating to the other one slightly trickier.

Member

SomeoneWeird commented Dec 2, 2014

Apparently, package managers have a way to mark a package as "conflicting" with another.

For sure, I guess it just makes testing/migrating to the other one slightly trickier.

@mikeal mikeal referenced this issue in nodejs/roadmap Dec 2, 2014

Open

What is your biggest pain point w/ Node? #1

@paulohp

This comment has been minimized.

Show comment
Hide comment
@paulohp

paulohp Dec 2, 2014

👍 👏

paulohp commented Dec 2, 2014

👍 👏

@ehd

This comment has been minimized.

Show comment
Hide comment
@ehd

ehd Dec 2, 2014

I wonder what the plan is regarding the adoption of ES6 features. Specifically, modules and promises. iojs currently has competing technologies, and it could potentially transition. Would that trigger a major version increment, and therefore, be the 2.0.0 version?

@espadrine also very curious about that, that is ES6's general role in io.js. Given ES6 brings quite a large number of changes there will be a large amount of questions coming up.

Any ideas how & where to manage ES6 related issues? A meta issue, a label? If there already is documentation I apologise and humbly ask for a link.

ehd commented Dec 2, 2014

I wonder what the plan is regarding the adoption of ES6 features. Specifically, modules and promises. iojs currently has competing technologies, and it could potentially transition. Would that trigger a major version increment, and therefore, be the 2.0.0 version?

@espadrine also very curious about that, that is ES6's general role in io.js. Given ES6 brings quite a large number of changes there will be a large amount of questions coming up.

Any ideas how & where to manage ES6 related issues? A meta issue, a label? If there already is documentation I apologise and humbly ask for a link.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Dec 2, 2014

Member

@SomeoneWeird well, let's be clear and honest about all this. iojs is an alternative/replacement for the node binary distributed by Joyent. In this, I would expect test/migrating between the two to be similar in difficulty as testing/migrating to any new version of node.

Member

mikeal commented Dec 2, 2014

@SomeoneWeird well, let's be clear and honest about all this. iojs is an alternative/replacement for the node binary distributed by Joyent. In this, I would expect test/migrating between the two to be similar in difficulty as testing/migrating to any new version of node.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Dec 2, 2014

Member

@ehd and @espadrine one thing at a time, how about we release a stable version where generators don't require a rebuild :) But seriously, just taking new versions of v8 with some regularity will be miles ahead of where we are today.

Member

mikeal commented Dec 2, 2014

@ehd and @espadrine one thing at a time, how about we release a stable version where generators don't require a rebuild :) But seriously, just taking new versions of v8 with some regularity will be miles ahead of where we are today.

@SomeoneWeird

This comment has been minimized.

Show comment
Hide comment
@SomeoneWeird

SomeoneWeird Dec 2, 2014

Member

@mikeal Fair point, agreed.

Member

SomeoneWeird commented Dec 2, 2014

@mikeal Fair point, agreed.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Dec 2, 2014

Member

ES6

I think the responsible thing to do here is to take ES6 features as fast as v8 is adding them and then observe what effect that has in the ecosystem before making alterations to core. Seeing how the features are used should be a central part of deciding how they might be adopted in core and until we are taking new v8 releases regularly we can't really do that.

Member

mikeal commented Dec 2, 2014

ES6

I think the responsible thing to do here is to take ES6 features as fast as v8 is adding them and then observe what effect that has in the ecosystem before making alterations to core. Seeing how the features are used should be a central part of deciding how they might be adopted in core and until we are taking new v8 releases regularly we can't really do that.

@ehd

This comment has been minimized.

Show comment
Hide comment
@ehd

ehd Dec 2, 2014

@mikeal That sounds like a great plan. I'll get behind anything that empowers experimentation in the ecosystem and it looks like io.js will do a great job of that :)

ehd commented Dec 2, 2014

@mikeal That sounds like a great plan. I'll get behind anything that empowers experimentation in the ecosystem and it looks like io.js will do a great job of that :)

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Dec 2, 2014

Member

I think the responsible thing to do here is to take ES6 features as fast as v8 is adding them and then observe what effect that has in the ecosystem before making alterations to core.

I agree with this in general. For example everyone likes to talk about modules (which of course aren't in V8 yet and there aren't any commits showing progress in that direction, but that's another story). I think the fair thing to do is let the community build integration tooling, module loader, etc. and see what people like, before rolling the best solution into core.

FWIW the only features of ES6 that I think could potentially impact io.js core at all are modules and promises. Everything else (classes, arrow functions, etc.) really only impacts user code. Maybe proxies and weak maps would let us move some stuff out of C++ into JS.

Member

domenic commented Dec 2, 2014

I think the responsible thing to do here is to take ES6 features as fast as v8 is adding them and then observe what effect that has in the ecosystem before making alterations to core.

I agree with this in general. For example everyone likes to talk about modules (which of course aren't in V8 yet and there aren't any commits showing progress in that direction, but that's another story). I think the fair thing to do is let the community build integration tooling, module loader, etc. and see what people like, before rolling the best solution into core.

FWIW the only features of ES6 that I think could potentially impact io.js core at all are modules and promises. Everything else (classes, arrow functions, etc.) really only impacts user code. Maybe proxies and weak maps would let us move some stuff out of C++ into JS.

@nmn

This comment has been minimized.

Show comment
Hide comment
@nmn

nmn Dec 3, 2014

@domenic I think Promises don't need to affect core at all. They can remain in user code. Modules are the only conflicting feature. ES6 has 0 conflicts with ES5. Node.js only added CommonJS, and nothing else.

nmn commented Dec 3, 2014

@domenic I think Promises don't need to affect core at all. They can remain in user code. Modules are the only conflicting feature. ES6 has 0 conflicts with ES5. Node.js only added CommonJS, and nothing else.

@alexgorbatchev

This comment has been minimized.

Show comment
Hide comment
@alexgorbatchev

alexgorbatchev Dec 3, 2014

This is really exciting! Thanks for pulling the trigger on this.

What's the official message in terms of eco system fragmentation?

This is really exciting! Thanks for pulling the trigger on this.

What's the official message in terms of eco system fragmentation?

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Dec 3, 2014

Member

@alexgorbatchev there is no ecosystem fragmentation, there are 100K+ modules in npm that will work on iojs just like they work on nodejs. the only thing that is fracturing is the effort being put in to core, but if you take a look at the contribution graph for joyent/node there's nowhere to go but up :)

Member

mikeal commented Dec 3, 2014

@alexgorbatchev there is no ecosystem fragmentation, there are 100K+ modules in npm that will work on iojs just like they work on nodejs. the only thing that is fracturing is the effort being put in to core, but if you take a look at the contribution graph for joyent/node there's nowhere to go but up :)

@madbence

This comment has been minimized.

Show comment
Hide comment
@madbence

madbence Dec 5, 2014

I mean issues like #9, #11, and #5. These are huge breaking changes.

madbence commented Dec 5, 2014

I mean issues like #9, #11, and #5. These are huge breaking changes.

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Dec 5, 2014

Member

@madbence only #5 is a breaking change of those you list.

Member

domenic commented Dec 5, 2014

@madbence only #5 is a breaking change of those you list.

@madbence

This comment has been minimized.

Show comment
Hide comment
@madbence

madbence Dec 5, 2014

@domenic my bad, you're right about #11. Maybe I misunderstand #9, but for me it means that I have to list eg. http as a dependency (if it's not part of the core), so every npm module that uses http will break. Fix me if I'm wrong :-)

madbence commented Dec 5, 2014

@domenic my bad, you're right about #11. Maybe I misunderstand #9, but for me it means that I have to list eg. http as a dependency (if it's not part of the core), so every npm module that uses http will break. Fix me if I'm wrong :-)

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Dec 5, 2014

Member

@madbence I mean it's a pretty vague idea but I'd imagine that core comes bundled with some modules that you can override local versions of in your project using npm.

Member

domenic commented Dec 5, 2014

@madbence I mean it's a pretty vague idea but I'd imagine that core comes bundled with some modules that you can override local versions of in your project using npm.

@YurySolovyov

This comment has been minimized.

Show comment
Hide comment
@YurySolovyov

YurySolovyov Dec 5, 2014

I thought #9 is about developing projects separately (like libuv and node) ...

I thought #9 is about developing projects separately (like libuv and node) ...

@gkatsev

This comment has been minimized.

Show comment
Hide comment
@gkatsev

gkatsev Dec 5, 2014

Yeah, #9 is about making the core be multiple separate projects that get packaged up at the build step and that is what is distributed. It may or may not be a breaking change.

gkatsev commented Dec 5, 2014

Yeah, #9 is about making the core be multiple separate projects that get packaged up at the build step and that is what is distributed. It may or may not be a breaking change.

@cscott

This comment has been minimized.

Show comment
Hide comment
@cscott

cscott Dec 5, 2014

Contributor

WRT ES6 and Promises, I would certainly like to see a future where promisify-type methods aren't required. I've filed #88 for this. But that wouldn't be a backwards-incompability, except maybe for some existing functions which both take a callback and return a value. I don't know any of those off the top of my head.

WRT "changes other than dep upgrades and fixes required for 1.0" -- I think you shouldn't get hung up on the number. If there are incompatible changes that "should be made", just do them after 1.0 and increment the appropriate part of the version number as per semver. Lots of people use current node, it's plenty good enough to label as 1.0.

(My candidate for future possibly-incompatible change would be some reconciliation between node modules and ES6 modules -- but that's far in the future, no sense holding up 1.0 for it.)

Contributor

cscott commented Dec 5, 2014

WRT ES6 and Promises, I would certainly like to see a future where promisify-type methods aren't required. I've filed #88 for this. But that wouldn't be a backwards-incompability, except maybe for some existing functions which both take a callback and return a value. I don't know any of those off the top of my head.

WRT "changes other than dep upgrades and fixes required for 1.0" -- I think you shouldn't get hung up on the number. If there are incompatible changes that "should be made", just do them after 1.0 and increment the appropriate part of the version number as per semver. Lots of people use current node, it's plenty good enough to label as 1.0.

(My candidate for future possibly-incompatible change would be some reconciliation between node modules and ES6 modules -- but that's far in the future, no sense holding up 1.0 for it.)

@boneskull

This comment has been minimized.

Show comment
Hide comment
@boneskull

boneskull Dec 5, 2014

Contributor

w/r/t a symlink/alias for the node executable:

I think an alias to node would be useful but not by default. An uneducated user who doesn't know about the relationship between iojs and Node might not be expecting it.

Frequently in the scripts section of npm's package.json, a module will have this:

"scripts": {
  "install": "node scripts/install.js"
}

Why? Windows doesn't know what to do with a shebang:

#!/usr/bin/env node

...so the install script cannot be simply be an executable scripts/install.js.

If someone is using iojs, and no node executable is present, the package will fail to install.

If I understand how running scripts with npm works, a potential hack around this would be for the npm packaged with iojs to attempt to put a symlink to the iojs executable at ./node_modules/.bin/node. (Assuming you can do that sort of thing with Windows; I'm a bit out of practice.)

(Edited to reflect proposed name of executable in /node-forward#19)

Contributor

boneskull commented Dec 5, 2014

w/r/t a symlink/alias for the node executable:

I think an alias to node would be useful but not by default. An uneducated user who doesn't know about the relationship between iojs and Node might not be expecting it.

Frequently in the scripts section of npm's package.json, a module will have this:

"scripts": {
  "install": "node scripts/install.js"
}

Why? Windows doesn't know what to do with a shebang:

#!/usr/bin/env node

...so the install script cannot be simply be an executable scripts/install.js.

If someone is using iojs, and no node executable is present, the package will fail to install.

If I understand how running scripts with npm works, a potential hack around this would be for the npm packaged with iojs to attempt to put a symlink to the iojs executable at ./node_modules/.bin/node. (Assuming you can do that sort of thing with Windows; I'm a bit out of practice.)

(Edited to reflect proposed name of executable in /node-forward#19)

@jamonholmgren

This comment has been minimized.

Show comment
Hide comment
@jamonholmgren

jamonholmgren Dec 6, 2014

Out of curiosity, will io.js pull commits from node.js that make sense to apply, preserving some common git history beyond today?

Out of curiosity, will io.js pull commits from node.js that make sense to apply, preserving some common git history beyond today?

@mizchi mizchi referenced this issue in hokaccha/nodebrew Dec 6, 2014

Closed

io.js support #31

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Dec 6, 2014

Member

@jamonholmgren we already have pulled a couple in :)

Member

mikeal commented Dec 6, 2014

@jamonholmgren we already have pulled a couple in :)

@JamesKyburz

This comment has been minimized.

Show comment
Hide comment
@JamesKyburz

JamesKyburz Dec 6, 2014

This is awesome!

What do you think about the idea of adding iojs to n and nvm?

Easy to switch between versions for developers + should then work in all CI servers who support n/nvm.

This is awesome!

What do you think about the idea of adding iojs to n and nvm?

Easy to switch between versions for developers + should then work in all CI servers who support n/nvm.

@naholyr

This comment has been minimized.

Show comment
Hide comment
@naholyr

naholyr Dec 6, 2014

Contributor

Adding to nvm would be such a great thing, easy install = easy testing = easy adoption.

Contributor

naholyr commented Dec 6, 2014

Adding to nvm would be such a great thing, easy install = easy testing = easy adoption.

@cjihrig

This comment has been minimized.

Show comment
Hide comment
@cjihrig

cjihrig Dec 6, 2014

Contributor

@JamesKyburz @naholyr that is currently being discussed in #40

Contributor

cjihrig commented Dec 6, 2014

@JamesKyburz @naholyr that is currently being discussed in #40

@JamesKyburz

This comment has been minimized.

Show comment
Hide comment

@cjihrig ok thx!

@creationix

This comment has been minimized.

Show comment
Hide comment
@creationix

creationix Dec 7, 2014

Contributor

FWIW, nvm doesn't deal with symlinks at all. It works by putting a certain
version of node's bin folder front in the user's path in their current
shell session. Thus a user is able to have multiple shell sessions going
on at once with different versions of node in each one. And it can do this
without a subshell. n and nave use two other techniques and have their
own strengths and weaknesses.

But this means that if you want node in your path to run a certain
version of iojs, there needs to be a node binary in the iojs bin folder
or putting it first in the PATH won't mean anything.

On Sat, Dec 6, 2014 at 2:08 PM, James Kyburz notifications@github.com
wrote:

@cjihrig https://github.com/cjihrig ok thx!


Reply to this email directly or view it on GitHub
#28 (comment).

Contributor

creationix commented Dec 7, 2014

FWIW, nvm doesn't deal with symlinks at all. It works by putting a certain
version of node's bin folder front in the user's path in their current
shell session. Thus a user is able to have multiple shell sessions going
on at once with different versions of node in each one. And it can do this
without a subshell. n and nave use two other techniques and have their
own strengths and weaknesses.

But this means that if you want node in your path to run a certain
version of iojs, there needs to be a node binary in the iojs bin folder
or putting it first in the PATH won't mean anything.

On Sat, Dec 6, 2014 at 2:08 PM, James Kyburz notifications@github.com
wrote:

@cjihrig https://github.com/cjihrig ok thx!


Reply to this email directly or view it on GitHub
#28 (comment).

@igormelnick

This comment has been minimized.

Show comment
Hide comment
@igormelnick

igormelnick Dec 7, 2014

I think aliasing iojs to node should be used. It's generally a good practice, have a look at mysql/mariadb. You just install maria and you're ready to go.
Another option is to use iojs as a sub-version of node, which would still allow seamless switching.

I think aliasing iojs to node should be used. It's generally a good practice, have a look at mysql/mariadb. You just install maria and you're ready to go.
Another option is to use iojs as a sub-version of node, which would still allow seamless switching.

@Fishrock123 Fishrock123 referenced this issue in node-forward/discussions Dec 7, 2014

Open

About the IO.js 6 week update schedule #22

@caineio caineio added needs info and removed needs info labels Dec 8, 2014

@piscisaureus piscisaureus removed the need info label Dec 8, 2014

@guybrush

This comment has been minimized.

Show comment
Hide comment
@guybrush

guybrush Dec 9, 2014

looking forward to use my n-semver with semver'ed io.js :)

guybrush commented Dec 9, 2014

looking forward to use my n-semver with semver'ed io.js :)

@Nicolab

This comment has been minimized.

Show comment
Hide comment
@Nicolab

Nicolab Dec 13, 2014

Contributor

io.js takes a good direction, exciting!

Contributor

Nicolab commented Dec 13, 2014

io.js takes a good direction, exciting!

@Solido

This comment has been minimized.

Show comment
Hide comment
@Solido

Solido Jan 8, 2015

I was in doubt with node.js but I started to learn ES6 just by confidence in IO.JS to be the next platform

Solido commented Jan 8, 2015

I was in doubt with node.js but I started to learn ES6 just by confidence in IO.JS to be the next platform

@siliconprime-tung

This comment has been minimized.

Show comment
Hide comment
@siliconprime-tung

siliconprime-tung Jan 14, 2015

will it be released today?

will it be released today?

@mathiasbynens

This comment has been minimized.

Show comment
Hide comment
@mathiasbynens

mathiasbynens Jan 14, 2015

Contributor

@siliconprime-tung: It has been released already! Get io.js v1.0.1 here: https://iojs.org/

Contributor

mathiasbynens commented Jan 14, 2015

@siliconprime-tung: It has been released already! Get io.js v1.0.1 here: https://iojs.org/

@MoOx

This comment has been minimized.

Show comment
Hide comment
@MoOx

MoOx Jan 14, 2015

This issue should be closed.

MoOx commented Jan 14, 2015

This issue should be closed.

@chrisdickinson

This comment has been minimized.

Show comment
Hide comment
@chrisdickinson

chrisdickinson Jan 14, 2015

Contributor

Congrats all! Closing this as fixed. ❤️

Contributor

chrisdickinson commented Jan 14, 2015

Congrats all! Closing this as fixed. ❤️

@davidhuang3

This comment has been minimized.

Show comment
Hide comment
@davidhuang3

davidhuang3 Jan 14, 2015

Glad to see it.

Glad to see it.

@mgol mgol referenced this issue in creationix/nvm Jan 20, 2015

Merged

`io.js` support #616

aljachimiak added a commit to aljachimiak/node that referenced this issue Dec 1, 2016

aljachimiak added a commit to aljachimiak/node that referenced this issue Dec 1, 2016

test: changes var to const/let in tls-ecdh; #28 from nina16
This commit changes var to const/let in
test/parallel/test-tls-ecdh.js.

Note this was *part* of task 28 from NINA 2016. The file specified
in the task (/test/parallel/test-tls-ecdh-dge.js) did not exist
so I modified a file that was simmilar in name with the same noted
deficiencies.

aljachimiak added a commit to aljachimiak/node that referenced this issue Dec 1, 2016

test: changes var to const/let in tls-ecdh; #28 from nina16
This commit changes var to const/let in
test/parallel/test-tls-ecdh.js.

Note this was *part* of task 28 from NINA 2016. The file specified
in the task (/test/parallel/test-tls-ecdh-dge.js) did not exist
so I modified a file that was simmilar in name with the same noted
deficiencies.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment