-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
release/2.2 consumes an old version of Microsoft.NetCore.Platforms #3519
Comments
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. |
I assume there will also be a change needed in dotnet/versions to make the update step for |
Yeah 2.2.4 has missed the train |
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: then:
|
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. |
Hmm, looks like there are quite a few packages out there using 2.2.0. |
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? |
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. |
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
The text was updated successfully, but these errors were encountered: