Repository navigation
Adopt Semantic Versioning 2.0.0: returning X.Y.Z instead of vX.Y.Z for node -v #40964
Description
Activity
- changed the title
[-]Adopt Semantic Versioning 2.0.0: return `17.1.0` for `node -v`[/-][+]Adopt Semantic Versioning 2.0.0: returning `X.Y.Z` instead of `vX.Y.Z` for `node -v`[/+]on Nov 25, 2021 In case it helps with your use case, if you want the version without a
v, you can useprocess.versions.node.$ node -p process.versions.node 17.1.0 $
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.
This seems like a change that is guaranteed to break a lot of code for little or no upside.
Reacted by Luigi Pinca and Tierney CyrenThis seems like a change that is guaranteed to break a lot of code for little or no upside.
No one should update a major version without checking release notes, especially the section "Breaking changes". So, if such change would not be digged somewhere in a list of commits, then there should not be a problem.
For instance, the
17.1.0release introduced anasertfor importing JSON modules, which broke the native importing of JSONs, althoughassertis not at the stage 4 of TC39 and therefore is not supported by ESLint:import appConfig from "./appconfig.json" assert {type: "json"};
That was even not a major release, just a minor one but still broke a code, which used to work for several years (yes, I know it's under the flag, but still).
17.1.0release introduced anassertfor importing JSON modules, which broke the native importing of JSONsAnything experimental is explicitly opted-out from semver:
Lines 31 to 34 in d0b58c0
That's why importing a JSON module comes with a
ExperimentalWarning: Importing JSON modules is an experimental feature. This feature could change at any timewarning. FYI you can still use assertionless JSON imports if you are willing to use an extra flag, see #40758 (comment).No one should update a major version without checking release notes
Reading the release notes would not help you in case you are relying on an old version of a package or software that do expect to see a
vat the start of the output ofnode -v. Sure you can say it's on them, and they should either upgrade the other software, or keep using the old Node.js version, but to me that sounds like making the life of some of our users harder for the sake of correctness.FWIW, I checked the output of
--versionfor other software (git, deno, zsh, gh) and none of them output a semver-compatible string.Reacted by Mike B.FWIW, I checked the output of
--versionfor other software (git, deno, zsh, gh) and none of them output a semver-compatible string.I've just checked a value for
git --versionand got:git version 2.34.1.windows.1Well, if other significant projects aren't semver-compatible as well, then OK, although, it's always good to be a widely accepted standard compatible.
Thanks for opening the issue. I'm going to close this. If any collaborators think we should reconsider, please comment or reopen.
Reacted by Tierney Cyren
Is your feature request related to a problem? Please describe.
Following https://github.com/nodejs/node/discussions/40957, Node.js version format contains a
v-prefix prior the version, e.g.node -vreturnsv17.1.0. According to the https://semver.org/#is-v123-a-semantic-version,v17.1.0is not semver compliant.Describe the solution you'd like
Drop
vfrom the version number and return17.1.0fornode -v.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.