RDK0011 — Package left behind by a version bump

Severity: warning · Command: redecker check --online

You bumped EF Core. Your database provider stayed where it was. Restore said almost nothing.

Two families that have to move together

RDK0003 covers packages that must carry the same version. This covers something different: two independently versioned families that must move in step. EF Core says so directly:

Check that external database provider supports the version of EF Core you are using. New major versions of EF Core usually require an updated database provider.

Their version schemes do not line up, so no arithmetic can express the relationship. Oracle.EntityFrameworkCore versions itself 10.23.26300 — the major tracks EF Core, the rest is Oracle's own.

Why report what NuGet already knows

The obvious objection is that restore raises NU1608 for exactly this. It does. What it does with it is the problem — measured, not remembered:

What you pinned	Diagnostic	Restore	Build
Provider declares an unbounded minimum (8.0.11)	none at all	✅	✅
Above the range, provider constrains one package	NU1608 warning	✅	✅ and it runs
Above the range, provider constrains a family	NU1608 + NU1107 error	❌	—
Below the range	NU1605 error	❌	—

Row two is the whole reason this rule exists. Pomelo 9.0.0 declares Microsoft.EntityFrameworkCore.Relational [9.0.0, 9.0.999]. Pin 10.0.0 and restore succeeds, the build succeeds, and the program runs — with a provider sitting on a core version it explicitly says it does not support. The only trace is one warning, in a repository that probably already has some.

The other rows fail loudly and need no help from anybody.

There is no table to maintain

Every provider already declares its own range. Redecker reads it out of the nuspec rather than carrying a hand-maintained mapping that would rot the day a provider ships.

That also means nothing here is EF Core specific. The check is "package B declares a range on package A, this repository pins both, and the pin falls outside the range" — which covers ASP.NET Core integration libraries, analyzers tied to a compiler version, and test SDK and adapter pairs, without knowing any of them exist.

It names the fix, not just the breach

warning RDK0011: Npgsql.EntityFrameworkCore.PostgreSQL 9.0.4 does not support
                Microsoft.EntityFrameworkCore.Relational 10.0.4
    ... Npgsql.EntityFrameworkCore.PostgreSQL 10.0.3 is the newest release that accepts
    Microsoft.EntityFrameworkCore.Relational 10.0.4. Move both in one change: bumping either alone
    leaves the pair broken.

That last sentence is the point. This failure is manufactured by one-package-per-pull-request updaters: bumping the core package alone is individually reasonable and collectively wrong.

It will never tell you to go backwards

Asked which Pomelo release accepts EF Core 10.0.0, an unfiltered search answers 7.0.0 — and it is telling the truth, because Pomelo 7 declares an unbounded minimum and therefore admits anything above it. That is the same missing upper bound that makes restore silent in the first place, and acting on it would downgrade your provider by two majors to fix a version bump.

So only releases newer than the one you have are considered. When none of them work, the rule says that instead of inventing something:

    No release of Pomelo.EntityFrameworkCore.MySql is newer than 9.0.0, so there is nothing to move
    up to. Hold Microsoft.EntityFrameworkCore.Relational at a version
    Pomelo.EntityFrameworkCore.MySql supports until one ships.

Which is the correct answer, and one a version-bumping bot will never give you.

Why it is opt-in

redecker check --online

Every other thing check does reads files on disk. This one reads a nuspec per declared package, so it is behind a flag rather than quietly reaching the network in somebody's CI. Downloads share inspect's cache, and package versions are immutable, so a second run is nearly free.

Why a warning

It describes a mismatch that restore permits and that surfaces later. Marking it an error would claim the build is broken, which — as the table above shows — is precisely the case where restore has already failed and you did not need Redecker to tell you.