An installed package requires a newer Unity than the editor you're running

Every UPM package declares the Unity version it supports (unity and unityRelease in its manifest). When an installed package declares a minimum above the editor you’re running, you’re in an unsupported combination — which typically surfaces as compile errors in the package, missing APIs, or subtly broken behaviour rather than a clean refusal to install.

What the scan looks at

The resolved PackageInfo for every installed package, compared against Application.unityVersion. This is read from the package’s own declaration, so there are no false positives: either the package says it needs a newer editor, or it doesn’t.

Why it’s worth a Warning

This is the failure mode that wastes the most time during an upgrade, because the symptom appears far from the cause. A package built for a newer Unity can:

• fail to compile, taking every assembly that depends on it down with it,
• compile but call into APIs that behave differently, producing runtime bugs nobody connects to the package,
• pull in a shader or asset format the editor can’t read, which shows up as magenta or missing content (SHDR004).

And when a project won’t compile, Unity stops reloading domains — so you can end up debugging a stale build without realising it, which is its own afternoon.

How to fix it by hand

1. Downgrade the package to the highest version that supports your editor. Package Manager shows the version list; the manifest’s unity field for each is the thing to check.
2. Or upgrade the editor to the version the package expects — the right move when the package is something you can’t do without and the upgrade was on the roadmap anyway.
3. Or remove the package if it arrived as a transitive dependency of something you no longer need.

Pin whatever you land on in manifest.json rather than leaving a range that will drift the next time packages resolve.

What PerfLint does about it

Report-only. Choosing between downgrading a package and upgrading the editor is a project decision with a schedule attached to it, and neither belongs behind a button. The finding names the package, the version it declares, and your editor version, so the decision is a one-liner.

For the wider upgrade picture — input backends, obsolete APIs, deprecated packages, and the blockers that only appear once you’re already committed — see the Unity 6 upgrade checklist.