Target net10.0

[milanjaros]

Explicit support for .NET 10

Updated tests and CI to run on .NET 8 and .NET 10.

Motivation

For Consumers:

• Lower upgrade friction: Users can upgrade their app's Target Framework to .NET 10 with fewer surprises
• Stability for .NET 8 users: Teams staying on .NET 8 (LTS) are not forced into immediate ecosystem upgrades
• Clear support boundaries: Know exactly which .NET versions are officially supported
• Warnings: No need to bypass
  warning NU1608: Detected package version outside of dependency constraint: Npgsql.EntityFrameworkCore.PostgreSQL 9.0.1 requires EntityFrameworkCore (>= 9.0.0 && < 10.0.0) but version Microsoft.EntityFrameworkCore 10.0.0 was resolved.
  • It is a good practice to TreatWarningsAsErrors

For Maintainers:

• Predictable release path: Creates a clear base for future policy (e.g., eventually dropping .NET 8) with controlled, test-backed transitions
• Easier API/provider change management: Conditional deps make it straightforward to support multiple major versions temporarily
• Better regression detection: Per-framework CI results catch issues that might only manifest in certain runtimes

Future Extensibility:

• Adding .NET 11+ only requires updating Target Framework lists and conditionals

Technical Notes

• All changes are backward-compatible; existing .NET 8 builds remain unaffected
• No breaking API changes in Pgvector.EntityFrameworkCore code
• Both net8.0 and net10.0 binaries are included in a single NuGet package

Resolves #57

[roji]

What's the reason for doing this? Libraries targeting net8.0 can already be used as-is in applications targeting net10.0; targeting higher TFMs is generally only needed when one wants to use a new API.

[milanjaros]

Reason is described in the section Motivation. :) I tried to make it as clear and expressive as possible. Sure, we can bypass the Warning in our project but what about other 77.6K consumers?

[roji]

I think there's a bit of a conflation here between the .NET TFM being targeted (net8.0 vs. net10.0) and the EF version being used; for example, one can perfectly well use EF 8 on net10.0. In general, it's not recommended for the same nuget package to reference different versions of a dependency in different TFMs (unless there's a good reason for it).

See related conversation in #59. I do agree that we should publish a new version of pgvector which depends on EF 10.0.x; but I don't think the same version should depend on different versions based on TFM. As in #59, I'd suggest maybe just aligning pgvector versions with EF/Npgsql versions, so publish Pgvector 10.0.0, and in November 11.0.0. Or some other version scheme (e.g. 0.10.0 -> Npgsql/EF 10.0.x, 0.11.0 -> NpgsqlEF 11.0).

@ankane what do you think?

[ankane]

@milanjaros Thanks for the PR, but I'm not sure it's needed. Upgrading Npgsql.EntityFrameworkCore.PostgreSQL in your application should fix the warning.

@roji It doesn't seem like an additional version is needed until breaking changes with EF 11, and I'd like to keep them separate for now.

[roji]

Upgrading Npgsql.EntityFrameworkCore.PostgreSQL in your application should fix the warning.

That's true, but every one of your users will bump into this warning and need to do a manual upgrade - that's not ideal. In addition, in November of this year 8.0 and 9.0 go out of support, and at that point you certainly want a Pgvector that references EF 10; and we might as well just do that now rather than wait for November, no?

[ankane]

That's true, but every one of your users will bump into this warning and need to do a manual upgrade

That's not accurate. The warning only affects users who add Pgvector.EntityFrameworkCore but not Npgsql.EntityFrameworkCore.PostgreSQL, which should not be most users (using a transitive dependency directly isn't a good practice with any language).

[roji]

The warning only affects users who add Pgvector.EntityFrameworkCore but not Npgsql.EntityFrameworkCore.PostgreSQL, which should not be most users (using a transitive dependency directly isn't a good practice with any language).

That's quite standard practice, in my experience. At the very least in .NET, it's not common practice (nor recommended) to take a direct dependency from your project on all transitive dependencies, unless you specifically need a newer version than what's brought in transitively. You also can't really know when a new version of some dependency of yours suddenly adds a new transitive dependency (so that you can take a direct dependency on it too), so again you end up with a transitive dependency.

But in any case, this is something that we really will need to do in just a few months, as I wrote (since 8.0 and 9.0 are going out of support), so IMHO it seems to make sense to just it now and save people the warning. But if you have some reason to object we can do it in a few months instead.