Epic: 5.5.0 — EFCore.ComplexIndexes stays the EF Core 10 package

Goal

Decided 2026-10-19; this replaces the 10.0.0 rename the epic held until then.

The existing ids stay on EF Core 10 / .NET 10 (LTS, supported to 2028-11). They are not renamed or renumbered. The rename happens at the EF Core 11 boundary instead, as a new package, CodoMetis.EFCore.SchemaKit, starting at 11.0.0 (#37).

That way a consumer swaps packages once, in the same upgrade in which they move to EF Core 11 and its native complex-type indexes. The old plan had them rename on EF Core 10 and rewrite again on 11.

5.5.0 is the last minor with a change of its own: it makes the line refuse EF Core 11. After it, release/5.x takes fixes only. The features ROADMAP.md planned for 5.5.0 (4.1 descriptor differ, 4.2 delete constraints, 4.3) move to SchemaKit.

In scope

Refuse EF Core 11 at registration: EFCore.ComplexIndexes serves EF Core 10 only #55: refuse EF Core 11 at registration; the bug form and the READMEs point EF Core 11 users to SchemaKit.
Every finding of the 5.5.0 pre-tag analysis and consumer probe, decided 2026-10-20. They were filed under 5.5.1 and 5.6.0, but 5.5.0 is not tagged yet, so each ships here:
- Loud bugs and test gaps (patch-eligible, but nothing waits for a patch): Typed exclusion-constraint filters on non-string JSON members fail at apply (text > integer) #78, Dropping both tables of a temporal foreign key fails when the principal sorts first, Down() included #79, Typed filters: char comparisons render an integer, and HasValue and other scalar members fail at migrations add, not at the declaration #80, btree_gist is injected only for gist with '=', and UseMethod("GiST") skips it #81, Index and constraint names are not checked against table, view and sequence names in the schema #82, SQL Server: a second clustered complex index in a later migration, and an index named like the table's key, fail only at apply #90, EF Core major guard: registering the differ by hand bypasses it and fails with MissingMethodException #91 (a way around Refuse EF Core 11 at registration: EFCore.ComplexIndexes serves EF Core 10 only #55's guard), Fractional index storage parameters render with the current culture on the stock Npgsql path #97, and the guards Tests: ten seeded defects in the PostgreSQL satellite that the suite does not catch #83 and Tests: seeded defects in the core and SQL Server differs that the suite does not catch, and the model-less SQL Server rendering #96 (Tests: seeded defects in the core and SQL Server differs that the suite does not catch, and the model-less SQL Server rendering #96 also fixes the harness trap that hid SQL Server: a unique complex index over nullable columns admits only one row without a value #88).
- Silent bugs The core differ silently drops SQL Server and Npgsql index options when it diffs a model a satellite should #92, TPC with a concrete base: complex indexes, exclusion and temporal constraints land on the base table only #93 and Typed expression indexes: string concatenation with a nullable operand differs from EF Core (COALESCE) #94. Each needs a minor with ### Changed answers, and 5.5.0 is already that minor. It already moves CustomIndex:RenderingVersion to 3, so consumers re-create indexes and rewrite the snapshot once instead of twice.
- SQLite: re-create complex indexes after a table rebuild instead of refusing the migration #95 (SQLite re-creates complex indexes after a table rebuild), last. After the tag release/5.x takes fixes only, so it is 5.5.0 or never on 5.x. If its design stalls, close it as won't-do on 5.x and keep SQLite: a migration that rebuilds a table silently drops every complex index on it #86's refusal; SchemaKit does not need it, because EF Core 11 indexes complex properties itself.
Two test layers the 5.5.0 findings show missing, decided 2026-10-20. Shipping code is at 93% of lines and 82% of branches, yet those findings failed only at apply or differed from EF Core's own translation:
- Tests: a SQL Server integration lane that applies migrations to a live server #100: a SQL Server integration lane that applies migrations to a live server (SQL Server: ALTER COLUMN on a column under a complex index fails at apply (Msg 5074) #84, SQL Server: a unique complex index over nullable columns admits only one row without a value #88 and SQL Server: a second clustered complex index in a later migration, and an index named like the table's key, fail only at apply #90 failed only there).
- Tests: sweep typed filters and typed expression indexes against EF Core's ToQueryString #101: a parity sweep of typed filters and typed expression indexes against ToQueryString() (Typed filters use SQL null semantics: != and ! on a nullable operand drop NULL rows, a captured null renders = NULL #68, Typed filters double braces in string literals: x.Code != "{draft}" renders '{{draft}}' #70, Typed expression indexes render Substring and Trim differently from EF Core's queries, so no query uses them #72 and Typed expression indexes: string concatenation with a nullable operand differs from EF Core (COALESCE) #94 were each found by hand).
CI the 5.x line needs before release/5.x is cut, from the CI/CD scope analysis (2026-10-20):
- CI: one gate job as the only required build check #110: one gate job as the only required build check, so release/5.x copies one check and a new lane needs no protection edit.
- Release: run the full CI before publishing, and a nightly full run #111: release.yml runs every CI lane before it publishes, a nightly full run, and the SDK pinned in global.json. A fixes-only line sees few PRs, so drift has to be caught without them.
- CI: select the PostgreSQL, SQL Server, consumer and pack lanes from a derived map #112 (lane selection, and the SQL Server lane's own test project) moved to 11.0.0 under Epic: CodoMetis.EFCore.SchemaKit 11.0.0 — the EF Core 11 successor #37: on a fixes-only line it saves little.
docs: adopt the CodoMetis.ValueRanges changelog form #98: the changelogs adopt the CodoMetis.ValueRanges form, so the 5.5.0 notes are the first in it.
Tag v5.5.0, then cut release/5.x at the tag with main's branch protection. After that, main becomes the SchemaKit line (SchemaKit 11.0.0-preview.1: the first slice of the new API, on EF Core 11 / Npgsql 11 under the new ids #38).

Out of scope

Features, SQLite: re-create complex indexes after a table rebuild instead of refusing the migration #95 excepted (it removes the cost SQLite: a migration that rebuilds a table silently drops every complex index on it #86's refusal puts on SQLite users). Features go to SchemaKit.
Deprecating the ids on nuget.org. That happens only when EF Core 10 leaves support, with SchemaKit as the alternate. Deprecating now would tell EF Core 10 users not to use the only package that serves them.

Done when

Every sub-issue is closed (or SQLite: re-create complex indexes after a table rebuild instead of refusing the migration #95 closed as won't-do on 5.x).
5.5.0 is on NuGet.
release/5.x is cut at v5.5.0 and protected like main.
ROADMAP.md says the same (Rewrite ROADMAP.md for the SchemaKit spin-off: D3–D11 decided #41).

After #62 merges: release and cut steps for the maintainer

#62 (closes #55) carries the guard and opens 5.5.0. The steps below are the maintainer's: the tag, the nuget approval and the repository settings. I read the settings on 2026-10-19.

1. Tag and publish

git switch main && git pull --ff-only
git tag v5.5.0
git push origin v5.5.0

release.yml runs verify (the full suite, then pack). Approve the nuget environment and publish pushes the three packages. release then creates the GitHub release from ## 5.5.0 and attaches the SBOMs. The environment's deployment policy already allows v* tags, so later v5.5.x tags from release/5.x need no change.

2. Cut `release/5.x` at the tag

git push origin v5.5.0^{commit}:refs/heads/release/5.x

dotnet.yml and pr-hygiene.yml already run on release/**.

3. Copy `main`'s branch protection to `release/5.x`

As read from main: strict status checks Test (ubuntu-latest), Pack, Integration (PostgreSQL 18) and Consumer smoke test; PR required with 0 approvals; admins enforced; no force pushes, no deletions.

gh api -X PUT repos/CaffeinatedCoder/EFCore.ComplexIndexes/branches/release/5.x/protection --input - <<'JSON'
{
  "required_status_checks": { "strict": true, "contexts": ["Test (ubuntu-latest)", "Pack", "Integration (PostgreSQL 18)", "Consumer smoke test"] },
  "enforce_admins": true,
  "required_pull_request_reviews": { "required_approving_review_count": 0, "dismiss_stale_reviews": false, "require_code_owner_reviews": false },
  "restrictions": null,
  "allow_force_pushes": false,
  "allow_deletions": false
}
JSON
gh api repos/CaffeinatedCoder/EFCore.ComplexIndexes/branches/release/5.x/protection -q '.required_status_checks.contexts'

Approvals stay at 0, as on main. The tag ruleset "Release tags are immutable" already covers every v* tag.

4. Open 5.5.1 on `release/5.x`, in the first PR into it

Move Version to 5.5.1 and PackageValidationBaselineVersion to 5.5.0. In SECURITY.md, change the table to 5.5.x ✅ / < 5.5 ❌. SecurityPolicyConsistencyTests holds that row to the baseline, so it moves in the same commit.

5. `main` becomes the SchemaKit line (#38)

From here main takes no more 5.x work. #38 lists what changes there: the ids, net11.0, the version, docs and publishing. Two things from #62 that #38 has to handle on main:

EfCoreVersionGuard refuses every EF Core major except 10. On main it has to go, or move to the SchemaKit major.
The 5.x README sentence and the bug form's 10.x-only "EF Core version" field point at SchemaKit. On main they belong to SchemaKit's own README and form.

CONTRIBUTING.md's "Branches and releases" section and AGENTS.md still describe the old 10.0.0 rename and the net11 branch. #38 lists CONTRIBUTING's branch section; AGENTS.md's "Branches" bullet needs the same rewrite.

Pre-tag gate, 5.5.0 (`v5.4.1..934ec55`)

Verdict: hold the tag until #150 and #151 are settled, and #141, #142, #144 and #145 (with #143) have landed. Their PRs #146–#149 are open.

Hold the tag

UseComplexIndexes() on PostgreSQL or SQL Server still drops exclusion and temporal constraints and the IS NOT NULL filter without a word #150 (silent, high): UseComplexIndexes() on Npgsql or SQL Server still drops the exclusion constraint, the temporal constraint, the temporal FK and SQL Server: a unique complex index over nullable columns admits only one row without a value #88's IS NOT NULL filter, and applies cleanly. The core differ silently drops SQL Server and Npgsql index options when it diffs a model a satellite should #92 refuses only index options. Fixing this later changes an answer, which release/5.x cannot ship.
Release notes and packed READMEs link docs at blob/main, which becomes SchemaKit after the tag #151: the 5.5.0 release notes and packed READMEs link blob/main, which becomes SchemaKit after the tag. Published nupkgs cannot be changed.
An INCLUDE entry whose property was removed falls back to verbatim text, and PostgreSQL silently drops the index #142 (silent), The JSON date-vs-column filter check also runs on the source model, so a snapshot holding the filter cannot be diffed #144, SQL Server: a renamed complex index stays in the way of ALTER COLUMN, and the migration fails at apply (Msg 5074) #141, PostgreSQL TPC with a long derived table name: the default name is too long and an explicit name repeats, so no name passes #145 and A complex-index rename runs after a native CREATE INDEX that takes its old name (42P07) #143: filed earlier, still open on 934ec55. I reproduced SQL Server: a renamed complex index stays in the way of ALTER COLUMN, and the migration fails at apply (Msg 5074) #141 and PostgreSQL TPC with a long derived table name: the default name is too long and an explicit name repeats, so no name passes #145 again.

Before the tag, but not blocking it: docs #152, #153, #154; tests #155, #156, #157. The tests are the three seeded defects the 569-test unit suite did not catch.

Clean

Upgrade from 5.4.1: real v5.4.1 snapshots for PostgreSQL, SQL Server and SQLite, compiled and diffed. The first diff matched docs/upgrading.md exactly, and the second was empty. On PostgreSQL 18, the 5.4.1 create script, then Up → Down → Up, all applied, and the derived TPC table enforced its index and constraint (23505, 23P01).
Typed filters against C# evaluation: 52 + 27 lambdas, applied on PostgreSQL 18, with identical rows. The typed expression and JSON member indexes were picked by the planner for EF's own query.
EF Core 11 RC guard: all 12 entry points throw. 10.0.x patches pass.
SQLite wrapper (SQLite: re-create complex indexes after a table rebuild instead of refusing the migration #95): the refusal, the wired re-create and the unwired apply all behave as documented.
TPC × name checks, the identifier length, the SQL Server clustered slot, case-insensitive names, the relation namespace.
CI gate, release.yml → dotnet.yml, the newest-patch float (deps.json at 10.0.13/10.0.3), the release-notes rendering.
Seeded defects: 46, of which 43 were caught. Baseline: 569 unit tests and 25 PostgreSQL 16/18 integration tests, all passing.

Not covered: SQL Server live apply (amd64 image), Windows MSBuild .targets.

Doubts, not filed

Wired SQLite rebuilds are not atomic, because of EF's PRAGMA foreign_keys. EF's own indexes have the same limitation.
The nightly's dispatched release/5.x run shares a concurrency group with pushes, so a cancelled run might open a spurious "Nightly CI failed" issue.
Successor package naming: the satellite changelogs say CodoMetis.EFCore.SchemaKit.SqlServer, the guard message says CodoMetis.EFCore.SchemaKit.

Pre-tag sweep, 5.5.0 (`934ec55..eff80b4`)

I ran five lenses over the fixes since the gate (#146–#149, #162), #158, and the docs and tests (#159, #160, #165, #166). I reproduced every issue below on eff80b4 myself.

Verdict: hold the tag for #167 and #170. Settle #168 and #169 before the tag too, because the answer goes into the published packages.

Holds the tag

TPC base with two partial indexes or exclusion constraints over the same parts: no name passes on PostgreSQL or SQLite #167 (breaking, high): on a TPC base, two partial indexes or two exclusion constraints over the same parts with different filters can't be named in a way that passes, on PostgreSQL or SQLite. The differ says "leave the name out", and the declaration then requires names. 5.4.1 diffed this model cleanly. This is what PostgreSQL TPC with a long derived table name: the default name is too long and an explicit name repeats, so no name passes #145's fix left open.
Changed answers: typed filters over Trim/Substring are re-created too, but the guide and changelog name only expression indexes #170 (docs): typed filters over Trim/Substring are re-created, and the Trim filter changes which rows it covers. The guide and the ### Changed answers row mention expression indexes only. The changelog is packed as the release notes.

Decide before the tag

A temporal foreign key's TPC copy on a long derived table is not shortened, and a 5.4.1 model fails at the first migrations add #168 (breaking, medium): a temporal FK's TPC copy on a long derived table isn't shortened, so a 5.4.1 model fails at the first migrations add. The guide says these copies are shortened. An explicit name works around it.
A 5.4.1 satellite with core 5.5.0 is refused as the core differ; satellites accept any later core while binding to its internals #169 (medium): a 5.4.1 satellite with core 5.5.0 is refused as the core differ, even with UseNpgsqlComplexIndexes(). The satellites' >= dependency on core goes into the 5.5.0 nuspecs. A pin to [5.5.0] is cheap now and impossible later.

Before the tag, not blocking

Upgrade guide: 'nothing of it is applied' is false for an index declared with IsCreatedConcurrently() #171 (docs): "nothing of it is applied" is false for IsCreatedConcurrently() copies, whose commands run outside the transaction.
Core differ on SQL Server scaffolds a NULLS-ordered or expression index that fails at apply; the core README says migrations add fails #172 (low): the core differ on SQL Server scaffolds a NULLS-ordered or expression index that fails at apply. The packed core README says migrations add fails. A 5.5.x patch can move the refusal earlier.

Clean

Upgrade from v5.4.1 snapshots, eff80b4:
- PostgreSQL: 34 operations, each documented except Changed answers: typed filters over Trim/Substring are re-created too, but the guide and changelog name only expression indexes #170.
- SQL Server: 8 operations; the SQL Server: a unique complex index over nullable columns admits only one row without a value #88 filters and the TPC copy are documented.
- SQLite: 1 operation, the TPC copy.
- Second diff: empty on all three.
- On PostgreSQL 18, create script → Upgrade → Down → Upgrade all applied. The 60-character derived table enforced 23505, 23P01 and 23503 under its shortened names.
Packages:
- Nuspec release notes match an independent renderer of each changelog.
- The packed READMEs match their source byte for byte, with the link rewrite.
- All 44 repository links are at v5.5.0 and resolve, anchors included.
- release.yml's notes step extracts lines 19–73 exactly under bash 3.2 and 5.2, and fails on an empty section.
- consumer-smoke-test.sh passed in both modes.
- UseComplexIndexes() on PostgreSQL or SQL Server still drops exclusion and temporal constraints and the IS NOT NULL filter without a word #150's refusal fires from a packed consumer.
Sibling parity: the rename fallback for every kind and order, the TPC shortening (index, EX, AK), The JSON date-vs-column filter check also runs on the source model, so a snapshot holding the filter cannot be diffed #144 target-only, An INCLUDE entry whose property was removed falls back to verbatim text, and PostgreSQL silently drops the index #142 on both declaration styles, and the UseComplexIndexes() on PostgreSQL or SQL Server still drops exclusion and temporal constraints and the IS NOT NULL filter without a word #150 refusal against ImplicitFilter all agree.
Docs: every rendered sample in the PostgreSQL index and constraint pages matches its prose. The only changed code blocks are the PostgreSQL constraints doc shows the default temporal constraint name with a double underscore #154 name fix and two diagnostic queries.

Not covered: SQL Server live apply (none of the findings needed it, so nothing was dispatched), Windows MSBuild, an EF Core 11 refusal from a packed consumer, and the README's C# samples compiled verbatim.

Doubts, not filed

Shortened copy names can move from ~ to ~1 when a sibling table sorts first. That rebuilds a copy through drop/create, which is correct but unneeded.
On PostgreSQL 18, an explicit constraint name equal to a generated …_not_null constraint name would pass every check. Not reproduced.

5.5.0 released (2026-10-20)

Tag: v5.5.0 on 490b4de. The release run passed every lane (unit, PostgreSQL 16 and 18, SQL Server 2022, newest EF Core patch, consumer smoke test, pack), then verify, publish and the GitHub release.
NuGet: EFCore.ComplexIndexes, .PostgreSQL and .SqlServer 5.5.0 are on nuget.org. Each package's release notes are its changelog section, with the docs links frozen to v5.5.0. The satellites pin the core at exactly [5.5.0].
GitHub release: v5.5.0 is Latest, with the three CycloneDX SBOMs attached.
release/5.x: cut at the tag and protected like main, with the single required check CI (strict, admins enforced, no force pushes or deletions). It prepares 5.5.1 since chore: open 5.5.1 on release/5.x #178 (Open 5.5.1 on release/5.x #177).
Scope: 58 sub-issues, all closed. Moved out of 5.5.0 by decision: CI: select the PostgreSQL, SQL Server, consumer and pack lanes from a derived map #112 to 11.0.0 under Epic: CodoMetis.EFCore.SchemaKit 11.0.0 — the EF Core 11 successor #37, and CI: run the lanes when an upstream input changes, not every night (.NET 11 roll-forward included) #137 and After the cut, release/5.x's own changelogs and READMEs link main, and DocumentationLinkTests checks them against the 5.x tree #161 to 5.5.1.

Done-when, checked:

5.5.0 is on NuGet.
release/5.x is cut at v5.5.0 and protected like main.

Next on this line: 5.5.1 takes fixes only (#137, #161). main becomes the SchemaKit line (#38).

Navigation Menu

Repository navigation

Epic: 5.5.0 — EFCore.ComplexIndexes stays the EF Core 10 package #36

Goal

In scope

Out of scope

Done when

After #62 merges: release and cut steps for the maintainer

1. Tag and publish

2. Cut `release/5.x` at the tag

3. Copy `main`'s branch protection to `release/5.x`

4. Open 5.5.1 on `release/5.x`, in the first PR into it

5. `main` becomes the SchemaKit line (#38)

49 remaining items

Pre-tag gate, 5.5.0 (`v5.4.1..934ec55`)

Pre-tag sweep, 5.5.0 (`934ec55..eff80b4`)

5.5.0 released (2026-10-20)

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Epic: 5.5.0 — EFCore.ComplexIndexes stays the EF Core 10 package #36

Description

Goal

In scope

Out of scope

Done when

Activity

CaffeinatedCoder commented on Oct 19, 2026

After #62 merges: release and cut steps for the maintainer

1. Tag and publish

2. Cut release/5.x at the tag

3. Copy main's branch protection to release/5.x

4. Open 5.5.1 on release/5.x, in the first PR into it

5. main becomes the SchemaKit line (#38)

49 remaining items

CaffeinatedCoder commented on Oct 20, 2026

Pre-tag gate, 5.5.0 (v5.4.1..934ec55)

CaffeinatedCoder commented on Oct 20, 2026

Pre-tag sweep, 5.5.0 (934ec55..eff80b4)

CaffeinatedCoder commented on Oct 20, 2026

5.5.0 released (2026-10-20)

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

2. Cut `release/5.x` at the tag

3. Copy `main`'s branch protection to `release/5.x`

4. Open 5.5.1 on `release/5.x`, in the first PR into it

5. `main` becomes the SchemaKit line (#38)

Pre-tag gate, 5.5.0 (`v5.4.1..934ec55`)

Pre-tag sweep, 5.5.0 (`934ec55..eff80b4`)