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

Improve preview handling for dotnet workload search version #43890

Closed
dsplaisted opened this issue Oct 4, 2024 · 1 comment
Closed

Improve preview handling for dotnet workload search version #43890

dsplaisted opened this issue Oct 4, 2024 · 1 comment
Assignees

Comments

@dsplaisted
Copy link
Member

Currently, when searching for workload sets, the SDK will include preview versions if the .NET SDK itself is branded as preview:

versions = PackageDownloader.GetLatestPackageVersions(packageId, _numberOfWorkloadSetsToTake, packageSourceLocation: null, includePreview: !string.IsNullOrWhiteSpace(_sdkVersion.Prerelease))

Probably there should be a command-line parameter that controls this (ie --include-previews).

Additionally, checking _sdkVersion.Prerelease may not be the best option for the default behavior. A better option may be to base it on whether the SDK Feature band is a prerelease band. That way the behavior of stabilized and non-stabilized RTM-branded SDKs would be the same, where today it isn't.

Finally, currently if you run dotnet workload search version --include-previews, you get an IndexOutOfRangeException, instead of an error that --include-previews is unrecognized.

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Workloads untriaged Request triage from a team member labels Oct 4, 2024
@dsplaisted dsplaisted removed the untriaged Request triage from a team member label Oct 4, 2024
@Forgind
Copy link
Member

Forgind commented Nov 26, 2024

I can add support for --include-previews. (I think we'd originally discussed it as 'if people ask, we can add it' rather than building it in by default, but I think it's a pretty reasonable ask.) Why is having a non-stabilized RTM-branded SDK acting like a stable SDK a good thing?

Edit: I actually started working on this, started testing, and changed my mind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants