Correct dependency floors blocking the pending base and solver releases

[ChrisRackauckas-Claude]

Please ignore until reviewed by @ChrisRackauckas.

Unblocks the OrdinaryDiffEqBDF 2.4.1 and OrdinaryDiffEqSDIRK 2.8.2 registrations, which AutoMerge has been rejecting since 2026-07-29, and corrects four more floors of the same class found by auditing for it.

The floors

package	dependency	was	now	why
OrdinaryDiffEqCore	DiffEqBase	7.8	7.10	requires SciMLBase 3.40; no DiffEqBase below 7.10.0 permits it
OrdinaryDiffEqDifferentiation	DiffEqBase	7	7.10	same
OrdinaryDiffEqNonlinearSolve	DiffEqBase	7	7.10	same
OrdinaryDiffEqBDF	OrdinaryDiffEqCore	4.11	4.12	reads integrator.is_disco_step / disco_checkpoint
OrdinaryDiffEqFIRK	OrdinaryDiffEqCore	4.4	4.12	same (also bumped 2.5.0 → 2.5.1)
OrdinaryDiffEqSDIRK	OrdinaryDiffEqNonlinearSolve	2	2.6	imports can_smooth_est

DiffEqBase

Core, Differentiation and NonlinearSolve all declare SciMLBase = "3.40", but the first DiffEqBase whose own compat permits SciMLBase 3.40 is 7.10.0. With a "7" / "7.8" floor the resolver has no solution at all — this is why Pkg.instantiate() currently fails in every sublibrary on master:

ERROR: Unsatisfiable requirements detected for package DiffEqBase [2b5f629d]:
 ├─restricted to versions 7.8.0 - 7 by OrdinaryDiffEqCore, leaving only versions: 7.8.0 - 7.9.0
 └─restricted by compatibility requirements with SciMLBase to versions: 3.13.2 - 6.53.6 — no versions left

is_disco_step / disco_checkpoint

Both fields arrived on ODEIntegrator with the DISCO work merged 2026-07-29 (#3720) and are in no released Core — 4.12.0 is the first to carry them. Against Core 4.11.0, BDF fails to load:

ERROR: LoadError: FieldError: type OrdinaryDiffEqCore.ODEIntegrator has no field `is_disco_step`

FIRK reads the same fields, and its master tree already diverges from the registered 2.5.0 (which predates the usage), so it is bumped to 2.5.1 to make the corrected floor releasable. FIRK is not currently broken in the registry — the released 2.5.0 does not touch these fields.

can_smooth_est

Added to OrdinaryDiffEqNonlinearSolve in #3823. The version that first carried it was never registered — ONLS goes 2.5.0 → master 2.6.0 — so against any released ONLS, SDIRK fails to load:

ERROR: LoadError: UndefVarError: `can_smooth_est` not defined in `OrdinaryDiffEqSDIRK`

How I looked for the rest

This class has now bitten four times (#2600, #4078, #4079, and these two), and the previous audit in #4080 missed both of these because it only checked qualified OrdinaryDiffEqCore.<name> accesses and explicit import lists — it could not see struct-field additions or cross-sublibrary imports. So this time:

1. Diffed the ODEIntegrator struct between the registered Core 4.11.0 tree and master, then grepped every sublibrary for accesses to the added fields → BDF and FIRK, nothing else.
2. Cross-referenced every qualified access and explicit-import name in every sublibrary against the registered Core 4.11.0 tree → no sublibrary references a Core name absent at 4.11.0. The two struct fields are the only Core gaps.
3. Same check against the registered OrdinaryDiffEqNonlinearSolve 2.5.0 tree → can_smooth_est in SDIRK, nothing else.
4. Checked every package depending on DiffEqBase for a SciMLBase >= 3.40 requirement paired with a DiffEqBase floor below 7.10 → the three above.

Verification

Ran locally, not inferred:

• OrdinaryDiffEqSDIRK instantiates and loads against the in-tree OrdinaryDiffEqNonlinearSolve.
• OrdinaryDiffEqBDF instantiates, loads, and solves — FBDF() on a scalar decay problem returns 0.36790983175798864.
• lib/DiffEqBase with [sources] stripped (so registry-only dependencies, which is what AutoMerge does) resolves, loads, and its GROUP=Core suite passes.

Release order this enables

1. DiffEqBase 7.10.0 — already registered, New version: DiffEqBase v7.10.0 JuliaRegistries/General#162879
2. OrdinaryDiffEqCore 4.12.0 and OrdinaryDiffEqNonlinearSolve 2.6.0 — need this PR merged first
3. re-trigger OrdinaryDiffEqBDF 2.4.1 (General#162756) and OrdinaryDiffEqSDIRK 2.8.2 (General#162761)

Metadata-only apart from the FIRK version bump.

🤖 Generated with Claude Code

https://claude.ai/code/session_017ZqxphdTA1MydR1WXye9Jc

[ChrisRackauckas-Claude]

Pushed a second commit: three more floors of the same kind, found while pre-checking the release order.

OrdinaryDiffEqDifferentiation and OrdinaryDiffEqNonlinearSolve also require SciMLBase = "3.40", and no released sibling permits that — Core tops out at 4.11.0 (which declares SciMLBase = "3.39") and Differentiation at 3.5.0. So both are unresolvable as they stand:

Unsatisfiable requirements detected for package OrdinaryDiffEqCore:
  restricted to versions 4 by OrdinaryDiffEqDifferentiation, leaving 4.0.0 - 4.11.0
  restricted by compatibility requirements with SciMLBase to versions: uninstalled

package	dependency	was	now
OrdinaryDiffEqDifferentiation	OrdinaryDiffEqCore	4	4.12
OrdinaryDiffEqNonlinearSolve	OrdinaryDiffEqCore	4.6	4.12
OrdinaryDiffEqNonlinearSolve	OrdinaryDiffEqDifferentiation	3	3.6

Exactly four packages on master require SciMLBase 3.40 — DiffEqBase, Core, Differentiation, NonlinearSolve — so only their sibling floors need this. Everything still allowing SciMLBase 3.39 resolves fine against the released siblings and is untouched.

I first tried to generalise this into a repo-wide audit and got it wrong: the rule is not "every dependent of a 3.40 package needs a raised floor", it's "a package that itself demands 3.40 needs raised floors on its siblings". The first version flagged ~50 packages, nearly all noise. These three are what survives the corrected rule, and each is confirmed by an actual resolution failure rather than by the audit.

Corrected release order, now that DiffEqBase 7.10.0 has merged (JuliaRegistries/General#162879):

1. DiffEqBase 7.10.0 — done
2. OrdinaryDiffEqCore 4.12.0
3. OrdinaryDiffEqDifferentiation 3.6.0
4. OrdinaryDiffEqNonlinearSolve 2.6.0
5. re-trigger BDF 2.4.1 (General#162756) and SDIRK 2.8.2 (General#162761)

Verified: Core 4.12.0 with [sources] stripped now resolves against registry-only dependencies (picking DiffEqBase 7.10.0) and loads. ONLS and Differentiation instantiate and load in-tree; their registry-only check can only be run once Core 4.12.0 is registered.