Account for lack of baselining when moving to CSProj packages

[ericstj]

Description

When packing with PKGProj the package index + harvesting validation ensured our dependencies were rather current, even for those packages we were no longer building. We should make sure we think about how to handle this once moving to CSProj, so that we ensure that we ship 6.0 with the latest serviced dependencies.

If I look at

runtime/eng/Versions.props

Lines 82 to 115 in fb931c6

	<StyleCopAnalyzersVersion>1.2.0-beta.304</StyleCopAnalyzersVersion>
	<SystemBuffersVersion>4.5.1</SystemBuffersVersion>
	<SystemCollectionsVersion>4.3.0</SystemCollectionsVersion>
	<SystemCollectionsConcurrentVersion>4.3.0</SystemCollectionsConcurrentVersion>
	<SystemComponentModelAnnotationsVersion>5.0.0</SystemComponentModelAnnotationsVersion>
	<SystemDataSqlClientVersion>4.8.1</SystemDataSqlClientVersion>
	<SystemDiagnosticsContractsVersion>4.3.0</SystemDiagnosticsContractsVersion>
	<SystemDiagnosticsDebugVersion>4.3.0</SystemDiagnosticsDebugVersion>
	<SystemDiagnosticsTracingVersion>4.3.0</SystemDiagnosticsTracingVersion>
	<SystemDynamicRuntimeVersion>4.3.0</SystemDynamicRuntimeVersion>
	<SystemLinqExpressionsVersion>4.3.0</SystemLinqExpressionsVersion>
	<SystemMemoryVersion>4.5.4</SystemMemoryVersion>
	<SystemNetHttpVersion>4.3.4</SystemNetHttpVersion>
	<SystemNetPrimitivesVersion>4.3.1</SystemNetPrimitivesVersion>
	<SystemNumericsVectorsVersion>4.5.0</SystemNumericsVectorsVersion>
	<SystemReflectionMetadataVersion>5.0.0</SystemReflectionMetadataVersion>
	<SystemResourcesResourceManagerVersion>4.3.0</SystemResourcesResourceManagerVersion>
	<SystemRuntimeVersion>4.3.1</SystemRuntimeVersion>
	<SystemRuntimeExtensionsVersion>4.3.1</SystemRuntimeExtensionsVersion>
	<SystemRuntimeInteropServicesVersion>4.3.0</SystemRuntimeInteropServicesVersion>
	<SystemRuntimeInteropServicesRuntimeInformationVersion>4.3.0</SystemRuntimeInteropServicesRuntimeInformationVersion>
	<SystemRuntimeSerializationPrimitivesVersion>4.3.0</SystemRuntimeSerializationPrimitivesVersion>
	<SystemSecurityCryptographyAlgorithmsVersion>4.3.1</SystemSecurityCryptographyAlgorithmsVersion>
	<SystemSecurityCryptographyCngVersion>4.7.0</SystemSecurityCryptographyCngVersion>
	<SystemSecurityCryptographyPkcsVersion>4.7.0</SystemSecurityCryptographyPkcsVersion>
	<SystemSecurityCryptographyOpenSslVersion>4.7.0</SystemSecurityCryptographyOpenSslVersion>
	<SystemTextJsonVersion>6.0.0-preview.5.21226.1</SystemTextJsonVersion>
	<SystemRuntimeCompilerServicesUnsafeVersion>6.0.0-preview.5.21226.1</SystemRuntimeCompilerServicesUnsafeVersion>
	<SystemThreadingVersion>4.3.0</SystemThreadingVersion>
	<SystemThreadingTasksExtensionsVersion>4.5.4</SystemThreadingTasksExtensionsVersion>
	<SystemValueTupleVersion>4.5.0</SystemValueTupleVersion>
	<MicrosoftBclAsyncInterfacesVersion>1.1.1</MicrosoftBclAsyncInterfacesVersion>
	<MicrosoftWin32PrimitivesVersion>4.3.0</MicrosoftWin32PrimitivesVersion>
	<runtimenativeSystemIOPortsVersion>6.0.0-preview.5.21226.1</runtimenativeSystemIOPortsVersion>

I see a few cases of stale dependencies, or dependencies which are even a major release behind.

The fix here may be as simple as ensuring darc-subscriptions from past servicing releases which are still being built, and a manual pass over the list to ensure it's up to date for those repos which don't publish to darc. We could consider validation for this somewhere as well, or just remember to do a pass every release.

cc @Anipik @ViktorHofer @safern @joperezr

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to this area: @Anipik, @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

When packing with PKGProj the package index + harvesting validation ensured our dependencies were rather current, even for those packages we were no longer building. We should make sure we think about how to handle this once moving to CSProj, so that we ensure that we ship 6.0 with the latest serviced dependencies.

If I look at

runtime/eng/Versions.props

Lines 82 to 115 in fb931c6

	<StyleCopAnalyzersVersion>1.2.0-beta.304</StyleCopAnalyzersVersion>
	<SystemBuffersVersion>4.5.1</SystemBuffersVersion>
	<SystemCollectionsVersion>4.3.0</SystemCollectionsVersion>
	<SystemCollectionsConcurrentVersion>4.3.0</SystemCollectionsConcurrentVersion>
	<SystemComponentModelAnnotationsVersion>5.0.0</SystemComponentModelAnnotationsVersion>
	<SystemDataSqlClientVersion>4.8.1</SystemDataSqlClientVersion>
	<SystemDiagnosticsContractsVersion>4.3.0</SystemDiagnosticsContractsVersion>
	<SystemDiagnosticsDebugVersion>4.3.0</SystemDiagnosticsDebugVersion>
	<SystemDiagnosticsTracingVersion>4.3.0</SystemDiagnosticsTracingVersion>
	<SystemDynamicRuntimeVersion>4.3.0</SystemDynamicRuntimeVersion>
	<SystemLinqExpressionsVersion>4.3.0</SystemLinqExpressionsVersion>
	<SystemMemoryVersion>4.5.4</SystemMemoryVersion>
	<SystemNetHttpVersion>4.3.4</SystemNetHttpVersion>
	<SystemNetPrimitivesVersion>4.3.1</SystemNetPrimitivesVersion>
	<SystemNumericsVectorsVersion>4.5.0</SystemNumericsVectorsVersion>
	<SystemReflectionMetadataVersion>5.0.0</SystemReflectionMetadataVersion>
	<SystemResourcesResourceManagerVersion>4.3.0</SystemResourcesResourceManagerVersion>
	<SystemRuntimeVersion>4.3.1</SystemRuntimeVersion>
	<SystemRuntimeExtensionsVersion>4.3.1</SystemRuntimeExtensionsVersion>
	<SystemRuntimeInteropServicesVersion>4.3.0</SystemRuntimeInteropServicesVersion>
	<SystemRuntimeInteropServicesRuntimeInformationVersion>4.3.0</SystemRuntimeInteropServicesRuntimeInformationVersion>
	<SystemRuntimeSerializationPrimitivesVersion>4.3.0</SystemRuntimeSerializationPrimitivesVersion>
	<SystemSecurityCryptographyAlgorithmsVersion>4.3.1</SystemSecurityCryptographyAlgorithmsVersion>
	<SystemSecurityCryptographyCngVersion>4.7.0</SystemSecurityCryptographyCngVersion>
	<SystemSecurityCryptographyPkcsVersion>4.7.0</SystemSecurityCryptographyPkcsVersion>
	<SystemSecurityCryptographyOpenSslVersion>4.7.0</SystemSecurityCryptographyOpenSslVersion>
	<SystemTextJsonVersion>6.0.0-preview.5.21226.1</SystemTextJsonVersion>
	<SystemRuntimeCompilerServicesUnsafeVersion>6.0.0-preview.5.21226.1</SystemRuntimeCompilerServicesUnsafeVersion>
	<SystemThreadingVersion>4.3.0</SystemThreadingVersion>
	<SystemThreadingTasksExtensionsVersion>4.5.4</SystemThreadingTasksExtensionsVersion>
	<SystemValueTupleVersion>4.5.0</SystemValueTupleVersion>
	<MicrosoftBclAsyncInterfacesVersion>1.1.1</MicrosoftBclAsyncInterfacesVersion>
	<MicrosoftWin32PrimitivesVersion>4.3.0</MicrosoftWin32PrimitivesVersion>
	<runtimenativeSystemIOPortsVersion>6.0.0-preview.5.21226.1</runtimenativeSystemIOPortsVersion>

I see a few cases of stale dependencies, or dependencies which are even a major release behind.

The fix here may be as simple as ensuring darc-subscriptions from past servicing releases which are still being built, and a manual pass over the list to ensure it's up to date for those repos which don't publish to darc. We could consider validation for this somewhere as well, or just remember to do a pass every release.

cc @Anipik @ViktorHofer @safern @joperezr

Author:	ericstj
Assignees:	-
Labels:	area-Infrastructure-libraries, untriaged
Milestone:	-

[ViktorHofer]

I agree with your observation @ericstj and that's something that @joperezr shared as feedback as well back when I moved away from the upfront depproj restore. Even back then we hadn't had a mechanism to make sure that we always target the very latest when restoring into the refpath / runtimepath.

The list of packages that we control ourselves and that are still shipping is very small. Efforts like removing package dependencies across subsets in favor of using live dependencies (most likely via P2Ps) will help cutting down the list further. That said, as long as we support .NET Standard configurations in our packages we will likely need to depend on LKGs here, a famous example is System.Memory, so I agree that we should establish some form of procedure to avoid stale dependencies.

We intentionally didn't want to create subscriptions between releases as that complicates the dependency graph. Something that I already shared in the past is that for any package which doesn't ship in the latest band and which publishes to nuget.org we could consider using dependabot (which is even integrated into GitHub these days) to keep it up-to-date. That would also help with 3rd party tools like xunit, coverlet, etc.

[ericstj]

@ViktorHofer pinging here as you may have addressed this in your csproj conversion PR.

[ViktorHofer]

and a manual pass over the list to ensure it's up to date

I already did recently this but can't find the commit right now. If this issue doesn't track adding automation then I believe we can close it.

[ViktorHofer]

Closing as versions are up-to-date. That said, we should consider using dependabot in the repo.