Node.js version number format inconsistent with Semantic Versioning 2.0.0

[pubmikeb]

For some reason, the Node.js version format contains a v-prefix prior the version, e.g. node -v returns v17.1.0, while all other Semantic Versioning 2.0.0-based version numbers don't have such v-prefix, e.g. npm -v returns 8.1.4.

What's the reason for using v17.1.0 instead of 17.1.0?
Won't it be better to use a Semantic Versioning 2.0.0 compliend version number format for Node.js?

[aduh95]

Relevant section of the FAQ: https://semver.org/#is-v123-a-semantic-version

What's the reason for using v17.1.0 instead of 17.1.0?

I think the only reason is because Node.js predates semver (Node.js first commit was made on 2009-02-16, Node.js v0.0.1 was released on 2009-05-27; Semantic Versioning 2.0.0 was released on 2013-06-18, 4 years later (and the older commit of the semver project was made on 2009-12-15 semver/semver.org@ca64580)). At that time, there wasn't a standard to follow. Since then, I suppose no one changed it in case it would break something somewhere, and also it's "close enough" to actual semver for most use cases.

It would have been great to spot that before Node.js 10.0.0, as the string was already changing shape, it would probably have been the best time. I'm not sure if we should "fix" this at this point (or if we should wait for Node.js 100.0.0 😬), it's hard to tell how much breakage it could introduce.

[pubmikeb]

it would break something somewhere

It should not be a problem at all if implemented in a major version:

MAJOR version when you make incompatible API changes

Besides, if a Node.js version check implemented properly, not just substringing the first char, it should not break anything.

I've opened an issue: nodejs/node#40964.

[Trott]

It should not be a problem at all if implemented in a major version:

True if you maintain libraries used by a few thousand people. Not even close to true for Node.js.

Thanks for opening the discussion, but from my perspective, this change has no chance of being implemented because there is no significant practical upside and a lot of risk.

[bnb]

Agree with @Trott, re: impact. Also worth noting that the semver library has a clean method which effectively makes this a non-issue,