Epic: CodoMetis.EFCore.SchemaKit 11.0.0 — the EF Core 11 successor #37

Goal

The EF Core 11 / .NET 11 successor to EFCore.ComplexIndexes, under new ids: CodoMetis.EFCore.SchemaKit (kernel), CodoMetis.EFCore.SchemaKit.PostgreSQL and CodoMetis.EFCore.SchemaKit.SqlServer. Decided 2026-10-19; this replaces the 2026-10-18 plan for an 11.x line of the same package.

• It ships as 11.0.0-preview.N from main, and as 11.0.0 when it's ready. That doesn't have to be EF Core 11's GA day: nobody is stranded, because 5.x keeps serving EF Core 10 (Epic: 5.5.0 — EFCore.ComplexIndexes stays the EF Core 10 package #36).
• Version numbers track the EF Core major, as Npgsql and CodoMetis.ValueRanges do.
• The repository is renamed to CaffeinatedCoder/CodoMetis.EFCore.SchemaKit with the first preview. GitHub redirects the old URL.

This keeps issue #3's promise: two parallel packages from November 2026 until EF Core 10 leaves support.

A new API, not the old one renamed

Decided 2026-10-19 by the maintainer: SchemaKit gets an entirely new public API, designed in #61. The rule is the one the CodoMetis.ValueRanges range types follow: a declaration the database would reject does not compile. The design uses .NET 11 and C# 15 for that, closed hierarchies first of all. No preview ships the 5.x API under the new ids. What stays compatible is the DDL and the snapshot annotations (#58, #59), not the API.

Why a new package

EF Core 11 ships native HasIndex/HasKey/HasAlternateKey over complex-type properties, JSON-mapped paths and complex-collection paths (dotnet/efcore#31246). Npgsql 11 ships native WITHOUT OVERLAPS and PERIOD (efcore.pg#3708, #3710). The old name now describes what the platform does.

Because SchemaKit is a new package, it leaves those features out, with no [Obsolete] shims. It keeps what stays unique: expression and JSON-member indexes, typed filter predicates, exclusion constraints, NULLS FIRST/LAST, and the SQL Server options.

Why this name

EF Core resolves the model differ and the migrations SQL generator as single services. When two packages replace one, one of them silently loses. SchemaKit is the one owner of both in the CodoMetis family, and it offers a public contract that other packages plug into (#56, #57).

"Schema" is that boundary. Whatever needs the differ or the generator belongs here or plugs in, such as the migration-aware parts of ltree in the planned CodoMetis.Hierarchies. Types, operators and query translation stay out: ltree's in CodoMetis.Hierarchies, ranges in CodoMetis.ValueRanges.

DataKit was rejected: it's unspecific, and nuget.org already has a DataKit.* family of 17 packages, including DataKit.SQL.Postgresql and DataKit.ORM.

Sequence

1. SchemaKit API design: a declaration the database would reject does not compile #61: the API design, reviewed and merged as design/schemakit-api.md, with compile probes for every "does not compile" claim.
2. SchemaKit 11.0.0-preview.1: the first slice of the new API, on EF Core 11 / Npgsql 11 under the new ids #38: after v5.5.0, the release/5.x cut and SchemaKit API design: a declaration the database would reject does not compile #61, main is retargeted to EF Core 11 and renamed to the new ids. 11.0.0-preview.1 ships the first slice of the new API: the kernel plus at least one feature end to end.
3. SchemaKit: a public plugin contract, so packages contribute to the model differ and migrations SQL generator instead of replacing them #56, SchemaKit: fail at startup when another package has replaced the model differ or the migrations SQL generator #57, SchemaKit: snapshot format v2 and CodoMetis: annotation keys ship in 11.0.0; the 5.x format is read forever (D11) #58: the plugin contract, the ownership check and snapshot format v2, built to SchemaKit API design: a declaration the database would reject does not compile #61. They are public and permanent, so they land before 11.0.0.
4. SchemaKit: leave out what EF Core 11 and Npgsql 11 do natively; keep what stays unique #39: leave out what the platform does. Temporal keys are decided: left out, since Npgsql 11's native ones accept every ValueRanges column (feat: Npgsql 11's native temporal keys accept every range and multirange column CodoMetis.ValueRanges#335). The HasComplexIndex half is open.
5. SchemaKit: moving from EFCore.ComplexIndexes 5.x adds no migration, or exactly the one the guide documents #59: the package swap adds no migration.
6. Cross-tests with CodoMetis.ValueRanges on both lines: range and multirange columns as temporal-constraint periods and exclusion-constraint operands #42, CI matrix for two lines: release/5.x on .NET 10, main (SchemaKit) on .NET 11; PostgreSQL floor and 18 legs, SQL Server #43, Package validation on the SchemaKit line: no baseline until 11.0.0 #46: cross-tests, CI matrix, package validation.

Done when

• Every sub-issue is closed.
• Previews are published while EF Core 11 is in RC.
• The changelog opens 11.0.0 with the platform floor and what is left out, and the migration doc has the "EFCore.ComplexIndexes 5.x → SchemaKit" section.
• v11.0.0 is tagged and the three packages are on NuGet.
• CONTRIBUTING and SECURITY.md name both lines: SchemaKit 11.x on main, EFCore.ComplexIndexes 5.x on release/5.x.