Revert "System.CommandLine update" #77078
Conversation
dotnet-issue-labeler
bot
added
Area-Infrastructure
untriaged
dotnet-policy-service
bot
added
Community
| @@ -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.
What's the reason for the revert?
There was a problem hiding this comment.
@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.
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