Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Microsoft.DotNet.SDK.*: Side-by-side installation of minor and patch releases #198539

Open
marco-eckstein opened this issue Dec 12, 2024 · 2 comments
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation.

Comments

@marco-eckstein
Copy link
Contributor

.NET SDK minor and patch releases are installed side-by-side for the same major version. (I have checked this only for the .NET SDK 8 versions, but I assume it is like this for other major versions as well.) This is indeed necessary because there can be breaking changes within the same major version (intentional or due to bugs I don't know).

Despite the side-by-side installations, there are different package identifiers only for different major versions in WinGet, making it impossible to properly manage these installations using WinGet.

There should be a package identifier for each .NET SDK version instead or additionally.

@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Triage This work item needs to be triaged by a member of the core team. label Dec 12, 2024
@marco-eckstein
Copy link
Contributor Author

Side note regarding breaking changes within major versions:

.NET SDKs uses the version format x.y.znn:

x is the major version.
y is the minor version.
z is the feature band.
nn is the patch version.

(see https://learn.microsoft.com/en-us/dotnet/core/tools/global-json#rollforward)

The "feature band" can introduce breaking changes in at least one way: New code analysis rules can get added and enabled by default, breaking the build if TreatWarningsAsErrors is true.

@Dragon1573
Copy link
Contributor

.NET SDKs uses the version format x.y.znn:

x is the major version.
y is the minor version.
z is the feature band.
nn is the patch version.

The "feature band" can introduce breaking changes in at least one way: New code analysis rules can get added and enabled by default, breaking the build if TreatWarningsAsErrors is true.

I can't sure how many releases have been published for .NET SDK, so I'll use Python for an example.

  1. Python uses version x.y.z Semantic Versioning Pattern.
  2. We assume all released version are included in the repository.

Currently we only split different minor (x.y) versions between Python releases. So according to Status of Python versions, there will be 2 (v2.6 and v2.7) + 15 (from v3.0 to v3.14) different package identifiers (Python.Python.2.6 to Python.Python.3.14) included in our the repository.

Image

But what if we split by patch (x.y.z) versions? Here I use Huaweicloud Mirror for the example. There will be 192 (might less than this actually) package identifiers! I think it's TOO MANY for the repository.

Image
Image


Accept side-by-side installation for .NET SDK to "patch level versions" might not a good choice. 🤔

@stephengillie stephengillie added Issue-Bug It either shouldn't be doing this or needs an investigation. and removed Needs-Triage This work item needs to be triaged by a member of the core team. labels Dec 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation.
Projects
None yet
Development

No branches or pull requests

3 participants