Update global.json default SDK roll-forward behaviour

[elinor-fung]

Currently, if the SDK version is specified in global.json, the default behaviour is to roll forward only on patch versions. We should change this default to roll-forward to latest major for 8.0+.

See https://github.com/dotnet/designs/blob/main/accepted/2022/version-selection.md#default-sdk-roll-forward-behavior

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Currently, if the SDK version is specified in global.json, the default behaviour is to roll forward only on patch versions. We should change this default to roll-forward to latest major for 8.0+.

See https://github.com/dotnet/designs/blob/main/accepted/2022/version-selection.md#default-sdk-roll-forward-behavior

Author:	elinor-fung
Assignees:	-
Labels:	area-Host
Milestone:	8.0.0

[vitek-karas]

@richlander @marcpopMSFT does it still sound good to make this change? (in 8 now).

[marcpopMSFT]

Do we want this change? I would not expect this to be the rollforward behavior customers want. If they are specifying an SDK, I'd assume they want that feature band.

[vitek-karas]

I think the main worry is for cases where the project asks for 6.0, but the machine only has 7.0 SDK - in which case it won't build at all. We could go with just Major which should use 6.0 when available and if not allow roll forward over major version as well. But I'll leave it up to Rich as this was his idea originally.

[alexrp]

FWIW, in every project where I set the SDK version in global.json, it's because I want the development environment to be as predictable as humanly possible. I think that's a good engineering principle in general.

Just yesterday, updating one of my projects from 7.0.100 to 7.0.101 resulted in a build break because CA1819 suddenly fired on some code that it didn't previously. We're all only human and so breakage like this is going to slip through every so often. But it does mean that even the current default roll-forward behavior is questionable to me, let alone the proposed behavior here.

[marcpopMSFT]

Updating a patch version should not add a new CA rule. @jaredpar any ideas on CA1819 as reported above? going from feature band to feature band can bring in some changes like that as teams don't always wait for the major release to introduce new warnings though we're working on trying to tie new warnings to TFM opt-ins to help avoid that update breaking things.

I don't think customers who use global.json would want to pin to a precise version and never roll-forward at all as then you're never getting security updates which seems more critical than the predictability principal.

[elinor-fung]

Not going to be doing this now.