release/2.2 consumes an old version of Microsoft.NetCore.Platforms

[wtgodbe]

The release/2.2 branch is depending on Microsoft.NetCore.Platforms 2.2.0, which was last updated in November: https://github.com/dotnet/core-setup/blob/f95848e5243fafee7e535d6db4f8a7d227346cc3/dependencies.props#L19. Meanwhile, the 2.1 version of that package has been updated a few times since the november release of 2.2.0. Therefore, we should either ship the latest version of that package out of both 2.1 & 2.2 in CoreFx, or we should update 2.2's dependency to be on the latest 2.1 version. I would lean towards the 2nd option, but I'm open to persuasion.

CC @dagood @ericstj @ajcvickers @bricelam

See dotnet/efcore#14504

[ericstj]

I'd also lean towards the second option (do a diff between 2.2 and 2.1 to make sure 2.1 isn't missing anything) so that we don't need to keep sim-shipping these two.

Other things to consider: 2.2.0 version could be out in the wild and an upgrade to 2.2.0 would downgrade 2.1.x servicing. We can probably run a query against NuGet to find out if anyone is depending on 2.2.0. Ideally we unlist 2.2.0 and ensure everyone is referencing 2.1.x.

[wtgodbe]

@mmitche I assume we've missed the train for 2.2.4? If so, we'll have to wait for 2.2.5.

@ericstj how does one run a query against NuGet?

[wtgodbe]

I assume there will also be a change needed in dotnet/versions to make the update step for Platforms depend on CoreFx 2.1 rather than 2.2: https://github.com/dotnet/core-setup/blob/release/2.2/dependencies.props#L83-L87 @dagood is that correct?

[mmitche]

Yeah 2.2.4 has missed the train

[dagood]

I assume there will also be a change needed in dotnet/versions

That only changes triggers--this is a dependencies.props change. Depending on multiple build-infos that declare the same package id isn't generally supported by VersionTools... I think you could get it done by duplicating:

https://github.com/dotnet/core-setup/blob/f95848e5243fafee7e535d6db4f8a7d227346cc3/dependencies.props#L57-L60

then:

• Put the 2.1 build-info after the 2.2 one, because the first package id match found takes priority.
• Use DisabledPackages metadata to remove the Platforms package from the 2.2 build-info, so it "falls through" to the 2.1 build-info.

---

(Aside) By the way, it might look like this:

https://github.com/dotnet/core-setup/blob/f95848e5243fafee7e535d6db4f8a7d227346cc3/dependencies.props#L57

matches up with this:

https://github.com/dotnet/core-setup/blob/f95848e5243fafee7e535d6db4f8a7d227346cc3/dependencies.props#L83

and you could split that into CoreFX-2.1 and CoreFX-2.2, but those identities are only a convention and doesn't affect matchups. If they actually did match up, that would be a nice way to resolve this. Not sure if it would be quick to implement a mode that does that.

[ericstj]

I think you should be able to do that building a query using https://dataexplorer.azure.com/clusters/dotnettel/databases/Telemetry. I gave it a try and seems doable but couldn't figure out how to structure a package/version specific dependency query. @marklio may know, his Kusto-fu is greater than mine.

[ericstj]

Hmm, looks like there are quite a few packages out there using 2.2.0.

[wtgodbe]

Drat. So at the least we shouldn't delete the 2.2.0 package from NuGet. I still think we'd rather just ship the package from 2.1, but maybe this tips the scales far enough that we have to revert to sim-shipping?

[ericstj]

Just means that you're more likely for someone to downgrade without a "way out". Our current dual branch servicing lends it self to downgrades (2.2 RTM can downgrade 2.1 latest) but usually we have a "way out": reference 2.2 latest. If we stop producing 2.2 latest we don't have the way out. Once we have 3.0 latest that might be OK for this particular package since its just the RID graph.

[wtgodbe]

Resolved: https://github.com/dotnet/core-setup/blob/release/2.2/dependencies.props#L19