Align System.CommandLine version with SDK

[am11]

cc @ViktorHofer, @akoeplinger for some reason, auto-update is not working in runtime, as in; dotnet/sdk#40075.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

[am11]

Is it still necessary for source build? There is a separate (newer) version for source-build in the SDK repo as well: https://github.com/dotnet/sdk/blob/d0ccce00860ffdee00d7328705e841e4f785a999/src/SourceBuild/content/eng/Versions.props#L29

[ViktorHofer]

Yes we still need this for source-build. We should investigate why dependency flow doesn't work.

[am11]

I think it's the only one using libraries feed

runtime/NuGet.config

Line 18 in ae6ad88

<addkey="dotnet-libraries"value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-libraries/nuget/v3/index.json" />

and it's probably not configured in code flow?

What I understood from @adamsitnik is that they should be kept in sync across dotnet repos (dotnet/command-line-api#2146), so probably configuring auto-update (like dotnet/sdk has) is the right solution.

[ViktorHofer]

The subscription was disabled for main. I just enabled.

[ViktorHofer]

The update is now part of #103574. Let's close this PR. Thanks for bringing this up :)

[am11]

Awesome! 👍

[adamsitnik]

What I understood from @adamsitnik is that they should be kept in sync across dotnet repos

Correct.

We should investigate why dependency flow doesn't work.

I've not been involved in System.CommandLine for almost a year now, but my understanding was that S.CL publishes a new package after every PR gets merged and at that time we were introducing a lot of breaking changes and did want to address each of them separately in every repo. We wanted to do that on demand, when something that was merged was needed.

But this could have changed since then @baronfel@jonsequitur

[am11]

cc @ViktorHofer, @akoeplinger for some reason, auto-update is not working in runtime, as in; dotnet/sdk#40075.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

[am11]

Is it still necessary for source build? There is a separate (newer) version for source-build in the SDK repo as well: https://github.com/dotnet/sdk/blob/d0ccce00860ffdee00d7328705e841e4f785a999/src/SourceBuild/content/eng/Versions.props#L29

[ViktorHofer]

Yes we still need this for source-build. We should investigate why dependency flow doesn't work.

[am11]

I think it's the only one using libraries feed

runtime/NuGet.config

Line 18 in ae6ad88

<addkey="dotnet-libraries"value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-libraries/nuget/v3/index.json" />

and it's probably not configured in code flow?

What I understood from @adamsitnik is that they should be kept in sync across dotnet repos (dotnet/command-line-api#2146), so probably configuring auto-update (like dotnet/sdk has) is the right solution.

[ViktorHofer]

The subscription was disabled for main. I just enabled.

[ViktorHofer]

The update is now part of #103574. Let's close this PR. Thanks for bringing this up :)

[am11]

Awesome! 👍

[adamsitnik]

What I understood from @adamsitnik is that they should be kept in sync across dotnet repos

Correct.

We should investigate why dependency flow doesn't work.

I've not been involved in System.CommandLine for almost a year now, but my understanding was that S.CL publishes a new package after every PR gets merged and at that time we were introducing a lot of breaking changes and did want to address each of them separately in every repo. We wanted to do that on demand, when something that was merged was needed.

But this could have changed since then @baronfel@jonsequitur

[am11]

cc @ViktorHofer, @akoeplinger for some reason, auto-update is not working in runtime, as in; dotnet/sdk#40075.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

[am11]

Is it still necessary for source build? There is a separate (newer) version for source-build in the SDK repo as well: https://github.com/dotnet/sdk/blob/d0ccce00860ffdee00d7328705e841e4f785a999/src/SourceBuild/content/eng/Versions.props#L29

[ViktorHofer]

Yes we still need this for source-build. We should investigate why dependency flow doesn't work.

[am11]

I think it's the only one using libraries feed

runtime/NuGet.config

Line 18 in ae6ad88

<addkey="dotnet-libraries"value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-libraries/nuget/v3/index.json" />

and it's probably not configured in code flow?

What I understood from @adamsitnik is that they should be kept in sync across dotnet repos (dotnet/command-line-api#2146), so probably configuring auto-update (like dotnet/sdk has) is the right solution.

[ViktorHofer]

The subscription was disabled for main. I just enabled.

[ViktorHofer]

The update is now part of #103574. Let's close this PR. Thanks for bringing this up :)

[am11]

Awesome! 👍

[adamsitnik]

What I understood from @adamsitnik is that they should be kept in sync across dotnet repos

Correct.

We should investigate why dependency flow doesn't work.

I've not been involved in System.CommandLine for almost a year now, but my understanding was that S.CL publishes a new package after every PR gets merged and at that time we were introducing a lot of breaking changes and did want to address each of them separately in every repo. We wanted to do that on demand, when something that was merged was needed.

But this could have changed since then @baronfel@jonsequitur

[am11]

cc @ViktorHofer, @akoeplinger for some reason, auto-update is not working in runtime, as in; dotnet/sdk#40075.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

[am11]

Is it still necessary for source build? There is a separate (newer) version for source-build in the SDK repo as well: https://github.com/dotnet/sdk/blob/d0ccce00860ffdee00d7328705e841e4f785a999/src/SourceBuild/content/eng/Versions.props#L29

[ViktorHofer]

Yes we still need this for source-build. We should investigate why dependency flow doesn't work.

[am11]

I think it's the only one using libraries feed

runtime/NuGet.config

Line 18 in ae6ad88

<addkey="dotnet-libraries"value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-libraries/nuget/v3/index.json" />

and it's probably not configured in code flow?

What I understood from @adamsitnik is that they should be kept in sync across dotnet repos (dotnet/command-line-api#2146), so probably configuring auto-update (like dotnet/sdk has) is the right solution.

[ViktorHofer]

The subscription was disabled for main. I just enabled.

[ViktorHofer]

The update is now part of #103574. Let's close this PR. Thanks for bringing this up :)

[am11]

Awesome! 👍

[adamsitnik]

What I understood from @adamsitnik is that they should be kept in sync across dotnet repos

Correct.

We should investigate why dependency flow doesn't work.

I've not been involved in System.CommandLine for almost a year now, but my understanding was that S.CL publishes a new package after every PR gets merged and at that time we were introducing a lot of breaking changes and did want to address each of them separately in every repo. We wanted to do that on demand, when something that was merged was needed.

But this could have changed since then @baronfel@jonsequitur

[am11]

cc @ViktorHofer, @akoeplinger for some reason, auto-update is not working in runtime, as in; dotnet/sdk#40075.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

[am11]

Is it still necessary for source build? There is a separate (newer) version for source-build in the SDK repo as well: https://github.com/dotnet/sdk/blob/d0ccce00860ffdee00d7328705e841e4f785a999/src/SourceBuild/content/eng/Versions.props#L29

[ViktorHofer]

Yes we still need this for source-build. We should investigate why dependency flow doesn't work.

[am11]

I think it's the only one using libraries feed

runtime/NuGet.config

Line 18 in ae6ad88

<addkey="dotnet-libraries"value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-libraries/nuget/v3/index.json" />

and it's probably not configured in code flow?

What I understood from @adamsitnik is that they should be kept in sync across dotnet repos (dotnet/command-line-api#2146), so probably configuring auto-update (like dotnet/sdk has) is the right solution.

[ViktorHofer]

The subscription was disabled for main. I just enabled.

[ViktorHofer]

The update is now part of #103574. Let's close this PR. Thanks for bringing this up :)

[am11]

Awesome! 👍

[adamsitnik]

What I understood from @adamsitnik is that they should be kept in sync across dotnet repos

Correct.

We should investigate why dependency flow doesn't work.

I've not been involved in System.CommandLine for almost a year now, but my understanding was that S.CL publishes a new package after every PR gets merged and at that time we were introducing a lot of breaking changes and did want to address each of them separately in every repo. We wanted to do that on demand, when something that was merged was needed.

But this could have changed since then @baronfel@jonsequitur

[am11]

cc @ViktorHofer, @akoeplinger for some reason, auto-update is not working in runtime, as in; dotnet/sdk#40075.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

[am11]

Is it still necessary for source build? There is a separate (newer) version for source-build in the SDK repo as well: https://github.com/dotnet/sdk/blob/d0ccce00860ffdee00d7328705e841e4f785a999/src/SourceBuild/content/eng/Versions.props#L29

[ViktorHofer]

Yes we still need this for source-build. We should investigate why dependency flow doesn't work.

[am11]

I think it's the only one using libraries feed

runtime/NuGet.config

Line 18 in ae6ad88

<addkey="dotnet-libraries"value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-libraries/nuget/v3/index.json" />

and it's probably not configured in code flow?

What I understood from @adamsitnik is that they should be kept in sync across dotnet repos (dotnet/command-line-api#2146), so probably configuring auto-update (like dotnet/sdk has) is the right solution.

[ViktorHofer]

The subscription was disabled for main. I just enabled.

[ViktorHofer]

The update is now part of #103574. Let's close this PR. Thanks for bringing this up :)

[am11]

Awesome! 👍

[adamsitnik]

What I understood from @adamsitnik is that they should be kept in sync across dotnet repos

Correct.

We should investigate why dependency flow doesn't work.

I've not been involved in System.CommandLine for almost a year now, but my understanding was that S.CL publishes a new package after every PR gets merged and at that time we were introducing a lot of breaking changes and did want to address each of them separately in every repo. We wanted to do that on demand, when something that was merged was needed.

But this could have changed since then @baronfel@jonsequitur

[am11]

cc @ViktorHofer, @akoeplinger for some reason, auto-update is not working in runtime, as in; dotnet/sdk#40075.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

[am11]

Is it still necessary for source build? There is a separate (newer) version for source-build in the SDK repo as well: https://github.com/dotnet/sdk/blob/d0ccce00860ffdee00d7328705e841e4f785a999/src/SourceBuild/content/eng/Versions.props#L29

[ViktorHofer]

Yes we still need this for source-build. We should investigate why dependency flow doesn't work.

[am11]

I think it's the only one using libraries feed

runtime/NuGet.config

Line 18 in ae6ad88

<addkey="dotnet-libraries"value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-libraries/nuget/v3/index.json" />

and it's probably not configured in code flow?

What I understood from @adamsitnik is that they should be kept in sync across dotnet repos (dotnet/command-line-api#2146), so probably configuring auto-update (like dotnet/sdk has) is the right solution.

[ViktorHofer]

The subscription was disabled for main. I just enabled.

[ViktorHofer]

The update is now part of #103574. Let's close this PR. Thanks for bringing this up :)

[am11]

Awesome! 👍

[adamsitnik]

What I understood from @adamsitnik is that they should be kept in sync across dotnet repos

Correct.

We should investigate why dependency flow doesn't work.

I've not been involved in System.CommandLine for almost a year now, but my understanding was that S.CL publishes a new package after every PR gets merged and at that time we were introducing a lot of breaking changes and did want to address each of them separately in every repo. We wanted to do that on demand, when something that was merged was needed.

But this could have changed since then @baronfel@jonsequitur

[am11]

cc @ViktorHofer, @akoeplinger for some reason, auto-update is not working in runtime, as in; dotnet/sdk#40075.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

[am11]

Is it still necessary for source build? There is a separate (newer) version for source-build in the SDK repo as well: https://github.com/dotnet/sdk/blob/d0ccce00860ffdee00d7328705e841e4f785a999/src/SourceBuild/content/eng/Versions.props#L29

[ViktorHofer]

Yes we still need this for source-build. We should investigate why dependency flow doesn't work.

[am11]

I think it's the only one using libraries feed

runtime/NuGet.config

Line 18 in ae6ad88

<addkey="dotnet-libraries"value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-libraries/nuget/v3/index.json" />

and it's probably not configured in code flow?

What I understood from @adamsitnik is that they should be kept in sync across dotnet repos (dotnet/command-line-api#2146), so probably configuring auto-update (like dotnet/sdk has) is the right solution.

[ViktorHofer]

The subscription was disabled for main. I just enabled.

[ViktorHofer]

The update is now part of #103574. Let's close this PR. Thanks for bringing this up :)

[am11]

Awesome! 👍

[adamsitnik]

What I understood from @adamsitnik is that they should be kept in sync across dotnet repos

Correct.

We should investigate why dependency flow doesn't work.

I've not been involved in System.CommandLine for almost a year now, but my understanding was that S.CL publishes a new package after every PR gets merged and at that time we were introducing a lot of breaking changes and did want to address each of them separately in every repo. We wanted to do that on demand, when something that was merged was needed.

But this could have changed since then @baronfel@jonsequitur