Version selection improvements #259
Conversation
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
Co-authored-by: Omair Majid <omajid@redhat.com>
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
|
|
||
| Ideally, organizations could adopt the following approach for runtime management in their environments: | ||
|
|
||
| - Adopt and deploy new .NET versions into their environments quickly, with no impact on existing applications (already the case). |
There was a problem hiding this comment.
Did you want to cover the case of customers who want multiple apps running on multiple different runtime versions on the same server like some internal partners we have?
There was a problem hiding this comment.
Isn't that the same scenario? The implication here is that the new .NET version is for another app.
accepted/2022/version-selection.md
Outdated
| The most problematic behaviors today are: | ||
|
|
||
| - [Multi-level lookup](https://github.com/dotnet/sdk/issues/12353) can result in the global install location being used when a private location is intended. | ||
| - `global.json` defaults to no roll-forward by default, for the specified SDK version. This results in very fragile environments, by default. Instead, the version specified should be a version floor by default. |
There was a problem hiding this comment.
Also, we have a problem with rollforward and previews today though that may only affect .NET teams. Not sure if that should be included or not.
There was a problem hiding this comment.
Can you elaborate? You mean that we roll-forward to previews by default and we could reconsider that as part of his change?
accepted/2022/version-selection.md
Outdated
| } | ||
| ``` | ||
|
|
||
| The feature bands have a reason to exist. With each feature band (`.200`, `.300`, ...), there is typically a significant update in a tools component like Roslyn, MSBuild, or NuGet. There may be compatibility breaks. However, if there are significant breaks, that's probably something that needs to resolve. The feature bands are not intended for intentional breaking changes. |
There was a problem hiding this comment.
The SDK doesn't include intentional breaking changes in feature bands but tools have no awareness of feature bands. They treat them as VS releases and hold to no requirement of their being no breaking changes. We've been hit by this in the past where we thought the feature band was low risk but it turned out a change in nuget or roslyn was more significant. We may want to consider how to reconcile this with other tools teams as we can't limit them to one breaking change release a year but also don't want every feature band release to include customer risk.
There was a problem hiding this comment.
I feel like your comment and the text are saying the same thing. No?
Summary of significant changes:
global.jsonSDK version to a floor version, as opposed to the current pinning behavior.PATHSDK.Dependency on: https://github.com/dotnet/designs/blob/main/accepted/2022/disable-multi-level-lookup-by-default.md