Rework global.json behavior

[rmannibucau]

(pretty sure there is a ticket for that but didn't find it with github search so please feel free to flag it as duplicate if you have it handy)

Is your feature request related to a problem? Please describe.

I have a project requiring the sdk net8.0 (similarly 9.0) without a minor specifically.
Using global.json is pretty hard since it requires a specific version whereas we want a compatible version with respect of the version policy (latestMinor for ex).
Most CI will fail if you set 8.0.0 because it doesn't exist but depending the environment you can't set the latest - when the SDK is downloaded from a mirror for example - nor you can assume using 8.0.100 is a good choice.

Describe the solution you'd like

Idea is to respect the JSON spec, ie if you have a policy, use the version as a baseline so 8.0.0+latestMinor can resolve 8.0.400 for ex.
Ideally support x for wildcards would be neat but is not a requirement (8.x, 8.0.x) since it is redundant with the policy.

[baronfel]

Do you have a specific example we can look at? 8.0.100 + latestMinor should allow any 8.x feature band to resolve? It's also possible that different tools (AzDo's UseDotNet vs GitHub Actions's actions/setup-dotnet vs dotnet-install.sh) may interpret global.json differently, so if you have details about how you're installing or using global.json that would be helpful too.

[rmannibucau]

here is the global.json:

{
  "sdk": {
    "version": "8.0.100",
    "rollForward": "latestMinor",
    "allowPrerelease": false
  }
}

I go a lot of troubles with UseDotNet from az devops cause it relies on the dotnet release.json file which lists explicitly some versions and teamcity which seems to not respect it until configured to use it (which can only fail at build time) - but sdk can't help there.
Other cases I have are mainly dotnet-install.ps1/dotnet-install.sh but didn't spot much more issue there.

[baronfel]

Ok, so in this case I think you need to raise tickets over at https://github.com/microsoft/azure-pipelines-tasks/issues (perhaps my own issue microsoft/azure-pipelines-tasks#20289 is relevant?) to get these other tools to actually adhere to the semantics of global.json in CI the same way that the .NET Runtime/SDK do locally.

[rmannibucau]

@baronfel it exists but still global.json has some issues: 1. it uses a static version with a policy (rollforward) instead of an explicit pattern so it is wrongly integrated in most tools, 2. this releases.json file shouldn't be (https://github.com/dotnet/core/blob/main/release-notes/releases-index.json and children links) somehow and consumers should be able to use an immutable path probably.

So request to sdk is to make it closer to a registry like apache maven central has, which can be trusted with a clear versioning policy which is reliable with years.
Ack tools then will need to integrate it but it is easier if the semantic and feature is there.
I wouldn't request a deeper integration of releases.json is still moving since it will require tools to still play with local vs remote vs config role to make users happy.

Hope it makes sense.

[BenjaminBrienen]

This request doesn't make sense to me. rollForward allows you to use newer feature bands or minor versions with no "wildcard" versions required and without having to manually specify them.

[rmannibucau]

@BenjaminBrienen do you mean releases-index.json usage is broken as well and that all sdk versions will be immutable (as binaries)? if so it is fine to close this ticket for me but it was not clear upfront from the docs and integrators do assumptions which are not always that explicit to me.