initial release

[jonathanong]

when's the initial release of io.js? would love even just a beta version so we can start trying #!/usr/bin/env io.

[Mickael-van-der-Beek]

👍

[Fishrock123]

Depends on how the Joyent Node Advisory Board reacts, and the node-forward TC's response to that, afaik.

I suggested the executable be named iojs to avoid conflicts.

[mikeal]

the executable needs to be named node, there are far too many existing scripts that use #!/usr/bin/env node. we aren't going to break the ecosystem, that would be insane :)

[darrenderidder]

I agree - node isn't a trademarked term and we were all using node.js in the public domain long before Joyent came along. Trademarking a term in common usage is hard to defend. As for their advisory board, from what I've seen it's just a few big companies looking to stake out cloud-hosting fiefdoms, not based on concern for what developers need.

[rlidwka]

the executable needs to be named node

Having executable name "node" and project name "io.js" isn't great, because when somebody will search for node, they'll find node.js, not io.js. Just something to think of.

Maybe ask people to use #!/usr/bin/env js instead? Where "js" is a symlink to whatever js implementation installed on the system (debian-based distros use this thing already). Just a thought.

[dshaw]

I can't speak on behalf of the Advisory Board, but if the goal is to ship something that users can use, trying to ship node is bound to add latency. Shipping something differently named allows forward technical progress to be made. Resolving issues with scripts is straightforward. We already do this on most Debian distributions linking nodejs to node.

@rlidwka nice. Can you confirm the namespace is available in common distros?

[mikeal]

@dshaw what exactly is going to add latency?

[mikeal]

@rlidwka FYI, spidermonkey ships a js binary, and has been for a long time :)

[dshaw]

@mikeal Trademark issues aside, there's already a binary being distributed called node. In fact, there are two. If the binary is called something else, then it can just ship. If the binary "has to be node, then there a considerable amount of effort required to get that binary into distribution channels.

[indexzero]

I agree with @dshaw on the naming. It also makes it a clean break; avoids confusion. Further, speaking as a the author of a very popular global CLI module, forever, I will gladly update the bin script to find node or iojs.

[mikeal]

@dshaw there is no trademark issue with producing a node binary. To my knowledge nobody has ever claimed there was. The existing threats have been related to the project name "Node Forward" but claiming the trademark extends to the term "node" or the node binary would be pure lunacy and, to my knowledge, that claim has never been made.

As to the binary name "already existing" I have two problem with this.

The first is that "shipping something" is most easily accomplished in the short term by not producing binaries and focusing on source releases, moving on to binary releases for various platforms once a release cadence is established.

The second issue I have with this is that we actually are producing releases of node that implement an API people understand as node. If you compare this with the various competing Java implementations it would make sense to produce the same binary. For instance, Apache Harmony installs a java binary, as does every other JVM implementation http://harmony.apache.org/quickhelp_users.html . To bring us back around to the trademark issues, Oracle owns a trademark on exactly the phrase "java" in this exact context and is aggressive about enforcing it, yet it is well established that this just doesn't extend to the binary name, even after Oracle won their appeal copyrighting the Java API this is holding true, so...

@indexzero "avoids confusion" ??? nothing is more confusing than changing the name of the thing you run :)

[mikeal]

@dshaw also, note that the name of the binary and the "project name" for installation on various operating systems is not the same. It's possible that people would apt-get install iojs which then would install a node binary.

[indexzero]

@mikeal I disagree with your position. If a fork begins, it is (by definition) not node. It is certainly "node-like", but will likely diverge in important technical ways. Now lets consider the fact that:

"On average, no one knows anything"

Shipping a binary with the same name as what is was forked from will definitely cause confusion to people who don't understand why X doesn't work with "node" on their system. Where X is a feature implemented in iojs/node and not joyent/node or vice-versa.

[mikeal]

@indexzero again, this is a well established pattern across the differing JVM implementations.

[dshaw]

@mikeal Sorry, "trademark issues aside" was intended to mean that I was not taking in to consideration anything about naming that related to anything legal.

[rmg]

Is it iojs or io.js? If there is to be a new name, it would be great if it could be one new name. I still don't know whether joyent/node is node, nodejs, or node.js and it has always bothered me.

Having iojs (or io.js, whatever the project's name is) as a binary that is aliased as node seems like an appropriate thing for downstream packagers to do, and seems completely separate from whether the binary produced by make is iojs or node.

[mikeal]

After a short conversation with @indexzero it became clear that we were talking about two totally different things when we say "shipping a node" and we're actually in agreement about what should be done.

• apt-get install iojs
• installs iojs binary
• installer aliases node to iojs binary

Anybody disagree with that strategy?

[indexzero]

@mikeal yes, exactly. If a fork is to occur, it is not "shipping node", it is "preserving backwards compatibility with the node ecosystem via an alias". Something that could easily be turned off via a flag if so desired by the person installing it.

[rvagg]

As long as we understand that this will also likely involve marking an iojs package (rpm and deb) as "conflicting" with nodejs so that the user is forced to choose one or the other.

[mikeal]

@rvagg +1

[indexzero]

@rvagg +1 although it technically doesn't conflict with the mainline nodejs packages since they only install a nodejs binary right? Just the superior, more maintained versions of them that you're responsible for?

[rvagg]

sort of .. the ones that come out of debian now (last I checked) do nodejs but they also have a "nodejs-legacy" package that does the symlink and contains the conflict and users are encouraged to do both to make it work properly.

regardless though, shipping proper linux packages is going to mean we have to do this because it is a true conflict, I just want to make sure everyone is aware of this.

[indexzero]

@rvagg got it. Thanks for the clarification, still definitely a big +1 to informing folks about the conflict.

[rlidwka]

As long as we understand that this will also likely involve marking an iojs package (rpm and deb) as "conflicting" with nodejs

I think there will be no conflict, if everything is done properly.

1. package nodejs will install its binary into /usr/bin/nodejs
2. package iojs will install its binary into /usr/bin/iojs
3. package libmozjs will install its binary into /usr/bin/js17
4. update-alternatives will allow users to select /usr/bin/node to point to iojs or nodejs as they prefer
5. update-alternatives will allow users to select /usr/bin/js to point to any of them as they prefer

Now if you're a package maintainer, you should use:

• /usr/bin/env nodejs if your stuff is compatible with node.js, but not iojs
• /usr/bin/env node if your stuff is compatible with both node.js and iojs
• /usr/bin/env js if your stuff is just a general javascript file without any requires

Something like that. Maybe. I'm not sure, that's just a suggestion.

It's worth to ask debian TC about this, those guys also have ax25-node conflict to keep in mind.

[eddietejeda]

Debian has a standard way of handling these types of issues with "alternatives". Check out: https://wiki.debian.org/DebianAlternatives

The Debian alternatives system was originally created for Debian but has been picked up by other GNU/Linux software distributions. For example Red Hat now uses a fork of the code to maintain system software such as /usr/sbin/sendmail. On RHEL/Fedora /usr/sbin/sendmail is an alternatives symlink to either the classic Sendmail or to Postfix as alternative implementations of an MTA.

[yorkie]

if there are more and more ES runtimes to be born, then @rlidwka's comment is what I was thinking, +1 🏁

[dougwilson]

So in Node.js, we have process.version, process.arch, process.platform, and process.versions. There will definitely be a way to use something to tell if code is running in Node.js vs io.js, correct? I assume at least there won't be a process.versions.node entry and instead be like a process.versions.iojs entry?

Also, anyone know about how npm will deal with this? Will it start looking in engines.iojs in the package.json file for the version spec?

[othiym23]

Also, anyone know about how npm will deal with this? Will it start looking in engines.iojs in the package.json file for the version spec?

Not unless there is a specific reason that npm needs to know which fork it's running on. Pretty much everything I've heard about io.js (and I have my sources ;) leads me to believe that there will be earnest efforts made to prevent that level of divergence, so the npm CLI team's stance is that we will deal with this issue only if it becomes a problem.

[othiym23]

Also, I fixated on the npm piece of this (i.e. which features npm needs to run itself), but in general, if it gets to the point where there are serious concerns about platform portability between node and iojs, npm can address that, but it's my sincere hope that that doesn't become an issue.

[rlidwka]

I expect node.js to update v8 dep very slowly, and it will be a major source of incompatibility between node.js and io.js. I could easily imagine that io.js will support arrow functions soon, but node.js won't.

The one common case when engines hash is used is to lock node.js version to >= 0.11.4 because of the generator support. Essentially, it depends on v8 version, not node.js version.

So...

@othiym23 , would it make sense for npm to support engines: { v8: "..."} instead of engines: { node: "..." } ?

[dougwilson]

Yes, the v8 stuff is one of the immediate ways in which node.js and io.js are diverging and being able to ask for this in package.json is a concern.

But even then, bugs are just as important. Say my module doesn't work well because of a bug in Node.js (just think 0.10.1 and 0.10.2). Normally I would say >= 0.10.2 and be done with it. Now since io.js seems like it's going to fix some bugs that Node.js is still sitting on, I would not have a way to do this, since I cannot differentiate Node.js and io.js in the package.json specification...

[othiym23]

@rlidwka @dougwilson That is a larger discussion than I'm prepared to get into on this issue, but I think what I said above remains true: if and when this becomes an issue, npm will decide upon a strategy for handling this.

[chrislea]

Hi all. Sorry I am so late to the party on this one, day job has been keeping me very busy recently.

IMNSHO the correct way to deal with this, as expressed already by many in this thread, is to install an iojs binary and symlink it to /usr/bin/node via the Debian alternatives system. This basically is what I've been doing forever with my nodejs packages for Ubuntu (and now Debian via the NodeSource repo).

The package in Debian that historically has installed a binary to /usr/bin/node is a program used by HAM radio operators, and as I understand it, they've kindly agreed to rename their binary as "node" is now really understood by folks to be the JS runtime we all know and love. Ref: https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=165;filename=ax25-node.debdiff;att=1;bug=681361

It won't truly be phased out for a while, but things are going in that direction, so I don't see a practical problem with putting something at /usr/bin/node via packages. I would argue that anybody who might run into a conflict is going to be technically savvy enough to sort the situation out for themselves. And, if it's a goal of iojs in general to have any level of compatibility with nodejs, then having a node executable on the $PATH is simply a requirement.

Adding the needed Conflicts bits to the packages so that you can't have both nodejs and iojs installed at the same time is easy, and probably the right thing to do. But either would be accessed via /usr/bin/node.

I will of course defer to my colleagues at NodeSource if they think I'm wrong, but I think this is the way to do things that will work the best for the greatest number of people.

[rlidwka]

they've kindly agreed to rename their binary as "node" is now really understood by folks to be the JS runtime we all know and love.

There was no "kind agreement", only a flamewar in the mailing list and subsequent TC decision, forbidding both packages to use /usr/bin/node:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614907#108

[chrislea]

Sorry @rlidwka, sarcasm translates really poorly when typed sometimes.

[rvagg]

13th of January (or thereabouts)