-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Revert "System.CommandLine update" #77078
Revert "System.CommandLine update" #77078
Conversation
@@ -13,14 +13,14 @@ | |||
<Sha>3f926184cacc477e3ddccd1eb4f3ebcb9a2b81a5</Sha> | |||
<SourceBuild RepoName="source-build-reference-packages" ManagedOnly="true" /> | |||
</Dependency> | |||
<Dependency Name="System.CommandLine" Version="2.0.0-beta4.25072.1"> | |||
<Dependency Name="System.CommandLine" Version="2.0.0-beta4.24528.1"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the reason for the revert?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@adamsitnik you might want to mention the reason for the revert in an issue somewhere (maybe in command-line-api) and then link to that in all the revert PRs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Short answer: chicken-and-egg problem with the update in SDK and NuGet.Client repos.
Long answer: The breaking change introduced in System.CommandLine requires an update to SDK, which uses both System.CommandLine and NuGet.CommandLine.XPlat (a NuGet package from NuGet.Client repo that also relies on System.CommandLine). NuGet.Client repo uses a hardcoded version of SDK (9.0.2) to run their integration tests, which is using an older version of System.CommandLine and fails at runtime (because the types have been renamed). The NuGet.Client repo release schedule is not tied to .NET, but to VS, so their dev branch updates flow to both SDK/main and SDK/release/9.0.x. Unblocking the flow would require them to create dedicated branches (and cause a lot of work to sync all the changes), or use a workaround with multi-targeting (NuGet/NuGet.Client#6252). It was decided that the simplest solution will be to just wait until NuGet.Client creates a new branch for next VS release in April.
Reverts #76948
Edit: What's the reason for the revert?
Short answer: chicken-and-egg problem with the update in SDK and NuGet.Client repos that will be easier to solve in April.
Long answer: The breaking change introduced in System.CommandLine requires an update to SDK, which uses both System.CommandLine and NuGet.CommandLine.XPlat (a NuGet package from NuGet.Client repo that also relies on System.CommandLine). NuGet.Client repo uses a hardcoded version of SDK (9.0.2) to run their integration tests, which is using an older version of System.CommandLine and fails at runtime (because the types have been renamed). The NuGet.Client repo release schedule is not tied to .NET, but to VS, so their dev branch updates flow to both SDK/main and SDK/release/9.0.x. Unblocking the flow would require them to create dedicated branches (and cause a lot of work to sync all the changes), or use a workaround with multi-targeting (NuGet/NuGet.Client#6252). It was decided that the simplest solution will be to just wait until NuGet.Client creates a new branch for next VS release in April.
cc @jaredpar @ViktorHofer