Skip to content
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

Proposal: Need more options to configure node versions #147

Closed
am11 opened this issue Feb 26, 2015 · 17 comments
Closed

Proposal: Need more options to configure node versions #147

am11 opened this issue Feb 26, 2015 · 17 comments

Comments

@am11
Copy link

am11 commented Feb 26, 2015

@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
Copy link
Member

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
Copy link
Author

am11 commented Feb 26, 2015

@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
Copy link
Member

Oh, nice timing! :)

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

@FeodorFitsner
Copy link
Member

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

@gep13
Copy link

gep13 commented Feb 26, 2015

This:

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

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

@FeodorFitsner
Copy link
Member

Yeah, but we need Windows installer :-/

@am11
Copy link
Author

am11 commented Feb 26, 2015

@rvagg, any ETA on dist. binaries?

@rvagg
Copy link

rvagg commented Feb 26, 2015

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
Copy link
Member

Cool! Literally real-time :) Thanks!

@am11
Copy link
Author

am11 commented Feb 26, 2015

Thank you!

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

road runner

@FeodorFitsner
Copy link
Member

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

@am11
Copy link
Author

am11 commented Feb 27, 2015

👍

@rvagg
Copy link

rvagg commented Mar 1, 2015

@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
Copy link
Author

am11 commented Mar 1, 2015

@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
Copy link

rvagg commented Mar 1, 2015

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
Copy link
Author

am11 commented Mar 1, 2015

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

@rvagg
Copy link

rvagg commented Mar 1, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants