-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
mirror nodejs.org/dist to iojs.org/dist #420
Comments
Also, are there any legal reasons why that would be a bad idea? The MIT license specifically allows redistribution, right? |
Short-term, this would work (as io.js will never have a version now that is < 1.0.0) but what if Node.js were to decide to re-brand and release the long promised v0.12.0 as v1.0.0 next week? Now we have conflicting and overlapping version numbers. It is probably better, long term, to have n, nvm, nave, etc. just support tracking individual projects just like how in the Ruby community rvm makes it easy to swap between different interpreters. Let users set a default and eventually choose one project or another to be the default. |
@snostorm I am in regular communication with @shammond2000 and @tjfontaine, and I think the possibility of a collision there is extremely unlikely. v0.12 will release as v0.12, and the road forward is to eventually merge the projects. Everyone is aligned on that as a goal. |
fixes #64. when a given version is requested, https://iojs.org/dist and http://nodejs.org/dist are checked for that version, in that order. `latest` always refers to io.js, because checking for node 1.0 is a bit of a waste of user time. `stable` always refers to node.js, because there is no stable release of io.js yet, and we have no way of determining that programmatically yet anyway, pending nodejs/build#22. the two-repository fallback hackery can also disappear once nodejs/node#420 is fixed.
If this does happen, this will affect |
Add `io.js` support. This branch adds support for https://github.com/iojs/io.js / https://iojs.org/ The following features should now work: - `nvm install iojs` will install the latest `io.js` version. `nvm ls iojs` and `nvm use iojs` will function as you'd expect. - `nvm install node` will install the latest stable `node` version. `nvm ls node` and `nvm use node` will function as you'd expect. - In general, a specific `io.js` version can be referenced with the "iojs-" prefix. If `node` were to ever release a `v1.0.0`, `v1.0.0` would refer to `node`, and `iojs-v1.0.0` would refer to `io.js`. In the near future, `node-v1.0.0` will also refer to `node` unambiguously. This applies to all `nvm` commands, including working with aliases and `.nvmrc` files. - `io.js`, unlike `node`, does not have a SunOS binary. Please open an issue on https://github.com/iojs/io.js if this is actually a problem for anyone, as currently it seems like this won't be for anybody. **Note**: checksum support upon installation is currently disabled. Relates to nodejs/node#368. **Note**: installation of `io.js` directly from source (via the `-s` option) is not yet enabled. This will be added soon. Relates to nodejs/node#40 nodejs/node#420 Fixes #590
Closing this, as I think we are more or less mirroring the directory, and a few version managers have added io.js support. Let me know if we need to reopen this. |
The only thing left as far as http://nvm.sh is concerned is #368 - i'd prefer it if iojs.org also had "SHASUMS.txt", and it would allow |
@ljharb There's a (signed) SHASUMS256.txt. Doesn't that work? |
@bnoordhuis #368 describes the problem - not every system Is there a practical risk from SHA1 collision on a middleman-d tar download (where they hadn't already middlemann-d the checksum file), that doesn't exist with SHA256? |
It would be a lot easier for npm/nave/n if the nodejs.org/dist folder were mirrored at iojs.org/dist.
Would be a pretty simple one-time wget fetch. Any objections?
The text was updated successfully, but these errors were encountered: