global.json is ignored if the SDK version is not fully qualified

[MiniKeb]

Describe the bug

global.json SDK version and rollForward behaviour appears to be ignored if the version string doesn't contains exactly [major version].[minor version].[feature brand]

To Reproduce

By default dotnet --info provide me these info :

Environnement d'exécution :
 OS Name:     Windows
 OS Version:  10.0.22621
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\7.0.101\

Host:
  Version:      7.0.1
  Architecture: x64
  Commit:       97203d38ba

.NET SDKs installed:
  5.0.100-rc.2.20479.15 [C:\Program Files\dotnet\sdk]
  5.0.415 [C:\Program Files\dotnet\sdk]
  6.0.402 [C:\Program Files\dotnet\sdk]
  7.0.101 [C:\Program Files\dotnet\sdk]

In a project with a global.json :

❯ cat .\global.json; dotnet --version
{
  "sdk": {
    "version": "6.0",
    "rollForward": "latestMinor"
  }
}
7.0.101

I expected that dotnet --version provide me 6.0.402

By modifying the global.json file :

❯ cat .\global.json; dotnet --version
{
  "sdk": {
    "version": "6.0.0",
    "rollForward": "latestMinor"
  }
}
6.0.402

I don't understand why, the version need to be fully qualified ?
The version specified in the global.json file should be considered identically : "version": "6" = "version": "6.0" = "version": "6.0.0"

[nagilson]

I'm guessing it's a limitation of the implementation, it would be nice to support this. Might go on the backlog. Let's see.

[baronfel]

I could see auto-expansion. We'd need to coordinate with the runtime team to change the framework version parser to expand this kind of version number. That parser is here if anyone's interested. Then we'd have to argue that this meets the servicing bar if we wanted it to apply to 6.x or 7.x, which I'm not sure we could justify.

[marcpopMSFT]

It's unclear which version we would expand to as 6.0.1xx is predictable but anything else we'd have to read from releases.json. I'm not sure I like this because it is ambiguous. CC @elinor-fung @vitek-karas in case they have a different opinion as the work would have to happen in the host but I vote for moving this to the backlog and revisiting with more feedback.

[vitek-karas]

I don't think we need to go to releases.json for this to work. Basically the ask is that specifying 6.0 is semantically equivalent to specifying 6.0.0. That is omitting part of the version implies 0 for that version part. The parser we have currently is strict - and exactly according to the semver 2.0 spec: https://semver.org/#spec-item-2

A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version.

So far this has not been a problem because in almost every case the version number we parse is machine generated (runtimeconfig versions mostly). The global.json is more or less the only place where the version number is expected to be human written at least in some cases.

Personally I would not be against making the parser a bit less strict and imply 0 for missing parts.