Efcore: Patch 2.2 for upper dependency limit on NetTopologySuite

[roji]

EF Core 2.2's spatial support will not work with NetTopologySuite 2.0.0 because of breaking changes. We can update our nuget dependency to reflect that and help users catch it earlier instead of getting a cryptic MissingMethodException at runtime (e.g. #18172).

[IanKemp]

I feel like this one should be pretty high up on the priority list.

It's the dependency on NetTopologySuite.IO.SqlServerBytes that needs to be fixed. Currently it's >= 1.15.1 which will pull in 2.0.0, which has a dependency on NetTopologySuite 2.0.0, which causes everything to break.

The dep on NetTopologySuite.IO.SqlServerBytes should thus be amended to >= 1.15.1 && < 2.0.0.

[smitpatel]

2.2 goes out of support in December.

[IanKemp]

2.2 goes out of support in December.

And? A lot of people are still on 2.2 for various reasons and will continue to be, this is an incredibly easy issue to fix with literally zero impact except for a patch version number bump, and honestly it shouldn't be an issue at all because you guys should have coordinated better with the NTS team.

[bricelam]

NuGet should be way better about warning when it resolves dependencies spanning major versions...

[IanKemp]

NuGet should be way better about warning when it resolves dependencies spanning major versions...

NuGet should be way better at a whole bunch of things, such as actually working properly. But unfortunately we live in an imperfect world.

[roji]

It's totally trivial to do, I say let's just do it. It's true that 2.2 going out of support doesn't mean people won't continue using it.

[bricelam]

I'm all for proposing this and doing it if we can, but ultimately it's not our team that enforces the bar for patches, and I'm not optimistic

[roji]

Submitted #18192 to consider for servicing.

[ajcvickers]

This was rejected by .NET directors because the value is not high enough to meet the servicing bar, and it's also not clear how well NuGet handles these bounds across various types of dependencies.

[IanKemp]

This was rejected by .NET directors because the value is not high enough to meet the servicing bar, and it's also not clear how well NuGet handles these bounds across various types of dependencies.

A very disappointing decision.

The faster release cadence of Core/Standard vs Framework is only acceptable to corporates if the quality of releases is maintained. The directors would do well to remember this.

They would also do well to remember that "move fast and break things" is acceptable for startups and companies like Facebook whose software is internal. It's not acceptable for SDKs like .NET that third parties rely on for stability and predictability,

Be very careful of losing the corporate support that got .NET to where it is today.