Raise OrdinaryDiffEqCore floor to 4.11 for the lorenz_pref precompile workloads

[ChrisRackauckas-Claude]

Please ignore until reviewed by @ChrisRackauckas.

Fixes #4079.

What broke

#4005 added a non-isbits AutoDePSpecialize precompile workload built on OrdinaryDiffEqCore.lorenz_pref / lorenz_pref_params, and wired it into the @compile_workload block of eight sublibraries — BDF, Default, LowStorageRK, Rosenbrock, SDIRK, SSPRK, Tsit5, Verner — without raising any of their OrdinaryDiffEqCore compat floors.

That commit bumped Core 4.10.0 -> 4.10.1, but 4.10.1 was never registered: General goes 4.10.0 -> 4.11.0. So the first released Core carrying lorenz_pref is 4.11.0, while the sublibraries went out declaring OrdinaryDiffEqCore = "4.10" (Tsit5, Verner, SSPRK, Rosenbrock, LowStorageRK) or "4.8" / "4.8.1" (BDF, SDIRK, Default).

Any environment that holds Core at 4.10.0 therefore resolves a combination that fails to precompile:

ERROR: LoadError: UndefVarError: `lorenz_pref` not defined in `OrdinaryDiffEqCore`

This is the same class as #2600 and #4078 — a Core symbol referenced from a precompile workload with a floor that predates the symbol.

Verification

Reproduced and confirmed locally (Julia 1.12.4), not inferred:

$ julia --project -e 'using Pkg
    Pkg.add(name="OrdinaryDiffEqTsit5", version="2.1.1")
    Pkg.add(name="OrdinaryDiffEqCore", version="4.10.0")'
$ julia --project -e 'using OrdinaryDiffEqTsit5'
ERROR: LoadError: UndefVarError: `lorenz_pref` not defined in `OrdinaryDiffEqCore`

Same Tsit5 with Core 4.11.0:

$ julia --project -e 'using OrdinaryDiffEqTsit5
    prob = ODEProblem((u,p,t)->1.01u, 1/2, (0.0,1.0))
    println(solve(prob, Tsit5()).u[end])'
1.3728004409033048

And with this branch's Tsit5 (OrdinaryDiffEqCore = "4.11") dev'd into an environment already holding Core 4.10.0, Pkg upgrades Core rather than resolving the broken pair:

  [bbf590c4] ↑ OrdinaryDiffEqCore v4.10.0 ⇒ v4.11.0
  [b1df2697] + OrdinaryDiffEqTsit5 v2.1.2
solve ok: 1.3728004409033048

Audit

Rather than patch only Tsit5, I checked out the registered Core trees for every 4.x release (4.0.0 through 4.11.0, mapped from General's git-tree-sha1 back to monorepo commits) and cross-referenced every qualified OrdinaryDiffEqCore.<name> access and every using/import OrdinaryDiffEqCore: ... name in all 50 sublibraries against its declared floor:

sublibrary	old floor	missing at floor	first released in
BDF	4.8	AutoDePSpecialize, lorenz_p, lorenz_p_params	4.8.1
BDF	4.8	lorenz_pref, lorenz_pref_params	4.11.0
Default	4.8.1	lorenz_pref, lorenz_pref_params	4.11.0
LowStorageRK	4.10	lorenz_pref, lorenz_pref_params	4.11.0
Rosenbrock	4.10	lorenz_pref, lorenz_pref_params	4.11.0
SDIRK	4.8	AutoDePSpecialize, lorenz_p, lorenz_p_params	4.8.1
SDIRK	4.8	lorenz_pref, lorenz_pref_params	4.11.0
SSPRK	4.10	lorenz_pref, lorenz_pref_params	4.11.0
Tsit5	4.10	lorenz_pref, lorenz_pref_params	4.11.0
Verner	4.10	lorenz_pref, lorenz_pref_params	4.11.0

No other sublibrary references a Core name that is absent at its declared floor. All ten rows collapse to the same fix: floor 4.11.

Changes

OrdinaryDiffEqCore = "4.11" in all eight, plus a patch bump for the four whose current in-tree version is already registered:

• Rosenbrock 2.6.1 → 2.6.2
• SSPRK 2.2.1 → 2.2.2
• Tsit5 2.1.1 → 2.1.2
• Verner 2.2.1 → 2.2.2

BDF 2.4.1, SDIRK 2.8.2, Default 2.4.2 and LowStorageRK 3.2.2 are not yet registered, so their floors are corrected in place.

Metadata-only; the source in this repo is already correct.

Two follow-ups, not done here

1. The already-registered broken versions stay broken. Tsit5 2.1.1, Verner 2.2.1, SSPRK 2.2.1 and Rosenbrock 2.6.1 are in General declaring "4.10". An environment pinned to Core 4.10.0 (the Colab case in OrdinaryDiffEqTsit5 v2.1.1 does not work with OrdinaryDiffEqCore v4.10.0 #4079) can still resolve back to them. The complete fix is a retroactive Compat.toml amendment in JuliaRegistries/General raising those four entries to 4.11. I have not opened that — General is outside the repos I act on without asking. Say the word and I'll prepare it.

2. Nothing in CI catches this class. DowngradeSublibraries.yml lists OrdinaryDiffEqCore in its skip set, and it has to: every sublibrary's [sources] points OrdinaryDiffEqCore at ../OrdinaryDiffEqCore, so the in-tree Core is always what gets loaded and the declared floor is never exercised. Three occurrences now (OrdinaryDiffEqSymplecticRK v1.2.0 does not work with OrdinaryDiffEqCore v1.6.0 #2600, Release DelayDiffEq 6.1.1 and OrdinaryDiffEqDefault 2.4.2 with correct OrdinaryDiffEqCore floors #4078, OrdinaryDiffEqTsit5 v2.1.1 does not work with OrdinaryDiffEqCore v4.10.0 #4079). A job that, per sublibrary, resolves OrdinaryDiffEqCore at its declared floor from the registry and does nothing but using would have caught all three at PR time. Happy to write it as a separate PR.

---

Unrelated observation while testing: Pkg.instantiate() on any sublibrary currently fails on master, before this branch. In-tree Core requires SciMLBase = "3.40", but the newest registered NonlinearSolveBase (2.38.0) caps at SciMLBase = "3.37.0 - 3.39". General already carries a ["2.38.1 - 2"] SciMLBase = "3.37.0 - 3" entry, so this clears once NonlinearSolveBase 2.38.1 is registered. Pure ecosystem lag, nothing to do with this change — but it does mean I could not run the in-tree sublibrary test suites for this branch.

🤖 Generated with Claude Code

https://claude.ai/code/session_017ZqxphdTA1MydR1WXye9Jc