.NET 10 support

[realvizu]

Updated TargetFramework and EFCore package references to 10.0 in all projects.
Adapted tests to breaking changes in RelationalTestStore and MigrationsInfrastructureTestBase.ExecuteSqlAsync.
4 tests are failing.

[realvizu]

I've just discovered that Should_Handle_LargeDataset() was already failing on my machine before the .NET 10 update. Have no clue why.

The 3 other failing tests are in TimescaleDbMigrationsInfrastructureTests, so chances are that those are connected to the TimescaleTestStore changes. Most of the breaking changes in RelationalTestStore were sync methods changed to async.
So in GetOrCreateShared() I had to call store.InitializeAsync which I worked around by calling ".Result" which may be a bad choice.

[sebastian-ederer]

@realvizu I fixed the tests :)

EF Core introduced the new tests can_apply_two_migrations_in_transaction and Can_apply_two_migrations_in_transaction_async which were failing, because Npgsql does not support that two migrations can be applied with a single user-manage transaction.
The corresponding issue: npgsql/efcore.pg#3407

The other tests probably failed because the expected EfCore22ModelSnapshot was updated by EF Core.

I also updated the GitHub workflows to use .NET 10

[realvizu]

Any plans for when it will be released? Let me know if there’s anything I can help with.

[sebastian-ederer]

I need to decide on a release strategy first, so people who use the package in .NET 8 do not run into any issues. I am currently busy with other projects, so it might take some time, but I am at it. Maybe I'll just copy the approach of Npgsql, but that would increase maintenance a lot, because I'd have to maintain multiple versions at once.

[realvizu]

Sure, no worries. For now, I’m using the modified NuGet package from a private feed.

Regarding versioning and release strategy, one approach I’ve seen work well with minimal overhead is to bump the major version of the package for .NET 10 (to v1.0.0 in this case). This ensures that users on .NET 8 using v0.x aren’t affected. You could then focus new enhancements on the latest major version while providing only minimal maintenance for older versions by keeping a legacy branch. Is this similiar to the Npgsql approach that you mentioned?

[sebastian-ederer]

Yes, that's what Npgsql does. Npgsql also cherry picks some commits to apply fixes to multiple version. I am tending to this approach at the moment. However, there would also be the option to configure multiple target frameworks and dynamic dependencies in the .csproj files.

[sebastian-ederer]

I decided on a release strategy, now. I will support only the latest LTS and hotfixes for the previous (still active) LTS.