Closed dave-yotta closed 1 year ago
That comment is attempting to draw a line between Canonical produced .NET SDK packages (which by their decision only stay on the 7.0.1xx feature band') and Microsoft-produced SDKs (which also produce 200, 300, 400, etc as the releases progress). These scripts provide access to the Microsoft-authored SDK payloads, which is why you were updated.
You can use the other command line options in this acript to more explicitly control the version if you prefer, but the command you've shown grabs the latest stable 7.0 build at the time.
Ok, sounds like strict pinning using e.g. --version 7.0.103
is the only thing that's going to help. --quality
sounds interesting but I didn't understand it even after reading the docs.
Doesn't sound like an issue the install scripts could do anything about.
Ok, sounds like strict pinning using e.g.
--version 7.0.103
is the only thing that's going to help.--quality
sounds interesting but I didn't understand it even after reading the docs.Doesn't sound like an issue the install scripts could do anything about.
You don't need to pin it to a specific version. You can get the latest version of a specific channel by using the channel
option. For example, --channel 7.0.1xx
gets you the latest supported version of the 100-series channel. This ensures you aren't broken by any breaking changes that occur between SDK channels.
See install script options: https://learn.microsoft.com/dotnet/core/tools/dotnet-install-script#options
See more about SDK versioning here: https://learn.microsoft.com/dotnet/core/versions/#versioning-details
I have no idea what the versioning system here is, but I've finally nailed the problem down to this issue: https://github.com/dotnet/sdk/issues/30624#issuecomment-1431307560
Does the comment there indicate that install scripts should not be pulling this version if it's not in a "source build"?
Any way to get patch updates for sdk without bringing in breaking changes using
dotnet-install.sh
would be greatly appreciated.I am very confused.