Proposal: Need more options to configure node versions

[am11]

@FeodorFitsner, as you mentioned previously, we now have a cmdlet to install any node.js version on AppVeyor , which is just brilliant!

Most of the repos tend to test against the latest versions of node.js and io.js. In .travis.yml, if we only mention iojs (like this for instance), it will test against the latest released build of io.js: major.minor.patch.

Going by AppVeyor docs:

Any 1.x version automatically assumes you want io.js, so to switch to the latest version of io.js use this command:
Install-Product node 1.0

Today, the latest version of io.js is v1.3, and by setting 1.0 in our matrix, it installs:

Installing node 1.0.4 (x86)...

Proposal:

Introduce the following keywords for matrix:

Key	Description
runtime:	To specify which runtime to use, between node or iojs.
iojs:	The value for runtime.
node:	The value for runtime.
version:	To specify which version of the runtime to use. In absence of this, it will install latest version of the runtime. If user specifies major version, it will use latest minor and patch. If minor version is specified, it will use latest patch version of that major.minor. User can then also target the exact version major.minor.patch.

Example:

An example of YAML:

# arrays
matrix: 
  -
    runtime: node
    version: 0
  -
    runtime: node
    version: 0.10
  -
    runtime: iojs
    version: 1.2.0
  - runtime: iojs

Corresponding JSON:

{
  "matrix": [
    {
      "runtime": "node",
      "version": 0
    },
    {
      "runtime": "node",
      "version": 0.1
    },
    {
      "runtime": "iojs",
      "version": "1.2.0"
    },
    {
      "runtime": "iojs"
    }
  ]
}

The first one will target the latest version of node in major=0 branch (i.e. v0.12.0 as of today).
The second one will target 0.10.36 (latest in 0.10 branch).
The third will target the exact version of iojs (the penultimate version since latest is v1.3.0).
The last one will target iojs latest major, latest minor and latest patch versions, since the version identifier from the group is missing.

Benefit:

Users will not have to update their appveyor.yml each time the major, minor or patch versions of node or io.js are incremented.

[FeodorFitsner]

Hi Adeel,

Thanks for the proposal, I appreciate your thoughts!

A cool thing about Install-product cmdlet is that it already support specifying only major version to get either latest node.js or io.js.

Indeed, using Install-Product 0 switches to the latest node.js 0.12.0 and Install-Product 1 switches to the latest io.js 1.2.0 (sorry it's not yet 1.3.0 - will deploy today).

Look at this test build:
https://ci.appveyor.com/project/FeodorFitsner/simple-console/build/1.0.264

I'll update docs to reflect that.

[am11]

@FeodorFitsner, thanks for the update and adding it to the documentation. 👍

io.js has actually released v1.4.1 two hours ago! As this is evident, their release pace is many times faster than that of node.js. So if possible, please automate the process to detect new releases.

https://github.com/iojs/io.js/releases.atom and https://iojs.org/dist/latest/
vs.
https://github.com/joyent/node/releases.atom and https://nodejs.org/dist/latest/

[FeodorFitsner]

Oh, nice timing! :)

We are in the process of deployment workers update. Will put io.js 1.4.1 into this vehicle.

[FeodorFitsner]

Where is 1.4.1? Can't see it here https://iojs.org/dist/latest/

[gep13]

This:

https://twitter.com/rvagg/status/570763286968274944

Was 21 hours ago on their official twitter account. Nothing since.

[FeodorFitsner]

Yeah, but we need Windows installer :-/

[am11]

@rvagg, any ETA on dist. binaries?

[rvagg]

literally 4 minutes ago https://twitter.com/rvagg/status/571078034670772224 - https://iojs.org/dist/latest/

we had git/jenkins/build problems and took the time to ensure the builds were consistent

[FeodorFitsner]

Cool! Literally real-time :) Thanks!

[am11]

Thank you!

Told you, their pace is faster than the road-runner.

[FeodorFitsner]

New build worker images with io.js 1.4.1 have been just deployed.

[am11]

👍

[rvagg]

@FeodorFitsner io.js 1.4.2 was just released, we've discovered a bunch of deficiencies for Windows builds that haven't been properly caught by our CI setup, one particularly bad one has been fixed in 1.4.2 but we'll likely have a 1.4.3 (and maybe more) just for Windows fixes.

[am11]

@rvagg, by any chance this get fixed: nodejs/node#871? I am trying to wrap up node-sass vNext quickly to present worlds most simplest reproduction steps to those guys in order to prove this:

the binary that is built with iojs node_modules/pangyp/bin/node-gyp --rebuild does not work on windows with the same versioned node.exe that was packaged in iojs .msi like: node my-package, but only works like iojs my-package. Vice versa is also true!

It however works on Linux/Mac, because in those SKUs, node is a symlink to iojs and process.execPath returns iojs executable path.

If we use nvmw, this problem does not happen because nvmw only downloads iojs.exe, downloads the corresponding npm version separately and then injects its own alias-node.cmd as node.cmd in iojs-vx.y.z directory, which acts exactly like symlink on *nix.

[rvagg]

Related: nodejs/node#751

If you're able to propose a fix then I'd encourage you to do so @am11, we're in a situation of having limited capacity from Windows collaborators as well as not having an agreed upon approach to deal with this. A pull request by someone with an actual solution would at least create some movement towards a permanent fix even if not using the exact approach. Code gives you something to focus around, otherwise discussion could just go on and on.

Also, I'm not the person for this. I'm concerned but don't develop on Windows and the last deployment I worked on that involved Windows was a nightmare, mainly for Windows-reasons. Best to keep prodding on the io.js repo, but code speaks louder than prose.

[am11]

@rvagg, I agree. I will dig into it and if I get somewhere with my experiment, will send a PR. Thanks! :)

[rvagg]

@am11 also don't be afraid to PR an experiment even if it's really raw, it can be valuable for getting feedback.