There are a number of repositories that consume Arcade N but want to use a .NET SDK that is different from the version that Arcade defines. Example: Using Arcade 8 with a 9.0.100 SDK or Arcade 9 with a 10.0.100 SDK. This will unblock NuGet/NuGet.Client#6482
This will also help with untying Arcade and the .NET SDK by not requiring a very specific version anymore. The majority of repositories will still consume what is defined by Arcade though.
Feature request
Maestro (or whatever component updates a repo's global.json dotnet and sdk entries) should skip any update if the tools.pinned json element is present.
"tools": {
"dotnet": "9.0.106",
+ "pinned": true,
"runtimes": {
"dotnet": [
"8.0.12"
]
}
},As the .NET SDK flowing via Arcade is always one specific version, there's not really a need for a roll-forward equivalent.
There are a number of repositories that consume Arcade N but want to use a .NET SDK that is different from the version that Arcade defines. Example: Using Arcade 8 with a 9.0.100 SDK or Arcade 9 with a 10.0.100 SDK. This will unblock NuGet/NuGet.Client#6482
This will also help with untying Arcade and the .NET SDK by not requiring a very specific version anymore. The majority of repositories will still consume what is defined by Arcade though.
Feature request
Maestro (or whatever component updates a repo's global.json dotnet and sdk entries) should skip any update if the
tools.pinnedjson element is present."tools": { "dotnet": "9.0.106", + "pinned": true, "runtimes": { "dotnet": [ "8.0.12" ] } },As the .NET SDK flowing via Arcade is always one specific version, there's not really a need for a roll-forward equivalent.