The binary and long term compatibility with node

[jondavidjohn]

There has been a bit of discussion in #28 about what to name the binary. This probably deserves it's own discussion.

The proposed approach

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

presents some additional questions:

• how do node / iojs live side by side?
• is it a goal of iojs to be long-term compatible with node?

[mikeal]

is it a goal of iojs to be long-term compatible with node?

Initial releases, 100%, but being that we have no control over where Joyent will take their fork in the future we can't really commit to staying compatible with whatever they decide to do. If there is a divergence we might choose to deprecate the "node" binary which is one reason I think it's important to install the iojs binary as well.

[kenperkins]

I think that absent a node alias or binary, iojs would be DOA.

+1 on being able to defer the decision on deprecating node long term, also +1 on proactive thinking with doing an iojs binary now

[ghostbar]

FFmpeg was forked into LibAV, LibAV used the same FFmpeg binary names without any issue, at the end LibAV diverged a lot from FFmpeg removing bunchs of functionalities and then they stopped using ffmpeg binary name but people already migrated their scripts to libav if they actually used libav.

I think that was the right approach on the long-term and short-term.

(The example is based on the fact that FFmpeg may be even bigger than node and it worked).

Other thing, I remember the name node is already used by other binary from the ham-community (reason why node is Debian-based systems is usually called nodejs instead of plain node. I think that won't happen with iojs).

[mikeal]

@ghostbar thanks for that story, it's incredibly relevant and puts to ease some of the concerns we've had.

[kenperkins]

mariadb is another example of a fork that uses the same binary and directory naming conventions. Here's a web-page from their site:

https://mariadb.com/kb/en/mariadb/documentation/getting-started/binary-packages/installing-mariadb-binary-tarballs/

The've also diverged, but are still mysql.

[klaemo]

Another thing that'll come up is the engines field in package.json. There needs to be a way to differentiate between node and iojs.
Let's say, I build a module or an app that depends on some of the newer v8 features, I'd need a way to communicate that to the modules's consumers or the PaaS (in case of an app) or whatever.

[yuchi]

@klaemo’s point is important. And my 2¢: it should be io not iojs in the engines, even if it breaks vertical align with node.

[jondavidjohn]

While providing a node alias and having an expectation of compatibility, is there some plan to track explicit compatibility? A map of say iojs 1.x => nodejs 0.12.x?

see #46

[ghostbar]

IMO node was already too generic and as a consequence too bad, io would make it worst. It's not like this project is the only thing that will make I/O in a system, so it should be iojs.

[kenperkins]

fwiw, I just went through the mariadb-server install when installing over mysql-server on ubuntu using apt-get and the install succeeded without any warnings what-so-ever. It basically over-wrote my mysql install.

[jondavidjohn]

Good idea @kenperkins, interesting experiment.

[ghostbar]

@kenperkins that's because it uses the alternatives from Debian-based distros, where you can have it called the same way and link to mysql based on the alternatives proposed.

It's the same way with generic names like editor which in my case links to vim but in the default system links to nano.

[othiym23]

There are already at least two programming languages named io, and any two-character name should be considered a no-go. I would be interested in hearing arguments in favor of "io" over "iojs" for the binary name, but I feel like I need convincing.

[talon]

I don't think io should even be a consideration. Way too generic.

[kenperkins]

+1 for iojs in lieu of just io