Adopt Semantic Versioning 2.0.0: returning `X.Y.Z` instead of `vX.Y.Z` for `node -v`

[pubmikeb]

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 -v returns v17.1.0. According to the https://semver.org/#is-v123-a-semantic-version, v17.1.0 is not semver compliant.

Describe the solution you'd like
Drop v from the version number and return 17.1.0 for node -v.

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.

[Trott]

In case it helps with your use case, if you want the version without a v, you can use process.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.

[pubmikeb]

This 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.0 release introduced an asert for importing JSON modules, which broke the native importing of JSONs, although assert is 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).

[aduh95]

17.1.0 release introduced an assert for importing JSON modules, which broke the native importing of JSONs

Anything experimental is explicitly opted-out from semver:

node/doc/api/documentation.md

Lines 31 to 34 in d0b58c0

	> Stability: 1 - Experimental. The feature is not subject to
	> [Semantic Versioning][] rules. Non-backward compatible changes or removal may
	> occur in any future release. Use of the feature is not recommended in
	> production environments.

That's why importing a JSON module comes with a ExperimentalWarning: Importing JSON modules is an experimental feature. This feature could change at any time warning. 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 v at the start of the output of node -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.

[targos]

FWIW, I checked the output of --version for other software (git, deno, zsh, gh) and none of them output a semver-compatible string.

[pubmikeb]

FWIW, I checked the output of --version for other software (git, deno, zsh, gh) and none of them output a semver-compatible string.

I've just checked a value for git --version and got:

git version 2.34.1.windows.1

Well, if other significant projects aren't semver-compatible as well, then OK, although, it's always good to be a widely accepted standard compatible.

[Trott]

Thanks for opening the issue. I'm going to close this. If any collaborators think we should reconsider, please comment or reopen.