Replies: 2 comments 2 replies
-
Relevant section of the FAQ: https://semver.org/#is-v123-a-semantic-version
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. |
Beta Was this translation helpful? Give feedback.
-
It should not be a problem at all if implemented in a major version:
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: #40964. |
Beta Was this translation helpful? Give feedback.
-
For some reason, the Node.js version format contains a
v
-prefix prior the version, e.g.node -v
returnsv17.1.0
, while all other Semantic Versioning 2.0.0-based version numbers don't have suchv
-prefix, e.g.npm -v
returns8.1.4
.What's the reason for using
v17.1.0
instead of17.1.0
?Won't it be better to use a Semantic Versioning 2.0.0 compliend version number format for Node.js?
Beta Was this translation helpful? Give feedback.
All reactions