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

Working on 1.0.0 #253

Closed
wants to merge 1 commit into from
Closed

Working on 1.0.0 #253

wants to merge 1 commit into from

Conversation

rvagg
Copy link
Member

@rvagg rvagg commented Jan 8, 2015

Someone has to do it!

@Fishrock123
Copy link
Contributor

🎉

@dshaw
Copy link

dshaw commented Jan 8, 2015

👏👏👏

@bnoordhuis
Copy link
Member

LGTM :-)

@fundon
Copy link
Contributor

fundon commented Jan 8, 2015

rvagg added a commit that referenced this pull request Jan 8, 2015
PR-URL: #253
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
@cjihrig
Copy link
Contributor

cjihrig commented Jan 8, 2015

Thanks Rod! Landed in 8a0e7d6

@cjihrig cjihrig closed this Jan 8, 2015
@jaw187
Copy link

jaw187 commented Jan 8, 2015

Carlton Dance

@dougwilson
Copy link
Member

So process.versions.node === 'v1.0.0'? Any way to tell the runtimes apart?

@rvagg rvagg deleted the node_version_h_1.0.0 branch January 9, 2015 03:24
@rvagg
Copy link
Member Author

rvagg commented Jan 9, 2015

I was thinking that we should add a process.versions.iojs property but perhaps it's best to take the same approach as in browser-land where you feature detect rather than platform detect?

@dougwilson
Copy link
Member

I'm not saying I would be using it (though presumably npm would use it for engines matching in the package.json file, but that's another thing), but of course if it's there, people will use it. Can't image what would then happen if there was a Node.js 1.0.0 and it's wasn't the same ;)

@cjihrig
Copy link
Contributor

cjihrig commented Jan 9, 2015

I am in favor of adding process.versions.iojs if for no other reason than to identify node vs. io.js when someone opens an issue and doesn't know what they are running (I'm sure it will happen eventually, even with an iojs binary). Feature detection would be preferred as @rvagg said. If no one is strongly opposed, I'll open a PR.

@rvagg
Copy link
Member Author

rvagg commented Jan 9, 2015

the only ones with strong opinions on this I can imagine are @isaacs and perhaps @mikeal

@isaacs
Copy link
Contributor

isaacs commented Jan 9, 2015

\o/

@rvagg
Copy link
Member Author

rvagg commented Jan 9, 2015

@isaacs is that a +1 for an process.versions.iojs or just general excitement about 1.0.0?

@isaacs
Copy link
Contributor

isaacs commented Jan 9, 2015

@rvagg Just general excitement about 1.0.0.

Adding process.versions.iojs is unnecessary and I am opposed to it. Would that version ever !== process.version?

When do you need to feature-detect apart from the version number? Does anyone actually think that there will be a release of joyent/node that is 1.0.0, and not composed of this exact code and this exact set of people doing the release?

@algesten
Copy link

algesten commented Jan 9, 2015

Does anyone actually think that there will be a release of joyent/node that is 1.0.0, and not composed of this exact code and this exact set of people doing the release?

OT: @isaacs dropping the bomb? sounds almost like you don't believe in the work you do on the NAB? ;)

@quantizor
Copy link

process.runtime === 'iojs' ?

@yorkie
Copy link
Contributor

yorkie commented Jan 9, 2015

btw, in process.config it has many keys that prefixes with node like node_install_npm, we maybe remove the prefix completely?

@yorkie
Copy link
Contributor

yorkie commented Jan 9, 2015

and i think this should seem to be applied in joyent/node as well :(

@ruimarinho
Copy link

My only concern is how npm will be able to test the engines property as pointed out by @dougwilson. We can't expect joyent to keep 0.x forever.

@isaacs
Copy link
Contributor

isaacs commented Jan 10, 2015

@algesten I do believe that the JNAB is doing good work, and will get to a good place. But the place it'll get to is merging io.js into node, not creating a competing 1.0.0 release.

The post-io.js node will likely be 1.next or 2.0.0.

The version alone will thus be sufficient to differentiate.

@othiym23
Copy link
Contributor

@isaacs I think process.versions.iojs is useful for tooling that needs to know whether it's working with node or iojs, like node-gyp (see nodejs/node-gyp#564, which you may have other opinions about as well).

As a result, I put together PR #491. As I'm sure you know, I share your desire to see Node and io.js converge again ere long, but until then, having a simple way to tell them apart from inside the runtime is useful.

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

Successfully merging this pull request may close these issues.