Release DelayDiffEq 6.1.1 and OrdinaryDiffEqDefault 2.4.2 with correct OrdinaryDiffEqCore floors

[ChrisRackauckas-Claude]

Please ignore until reviewed by @ChrisRackauckas. Opened as a draft.

Metadata-only. Fixes two independent registry breakages; the source in this repo is already correct.

1. DelayDiffEq 6.1.0 is broken against every OrdinaryDiffEqCore ≥ 4.8.1

#3835 reworked limiters as solve-level options, taking DEOptions from 21 type params / 41 fields to 23 / 43 (stage_limiter!, step_limiter!). It updated lib/DelayDiffEq/src/solve.jl in the same commit, so the monorepo stayed self-consistent — monorepo CI builds with path = deps and never sees the mismatch.

What it missed: bumping DelayDiffEq's version and its OrdinaryDiffEqCore floor. DelayDiffEq 6.1.0 was registered from 56ffb5267 (2026-07-23 15:22), three hours before #3835, and declares OrdinaryDiffEqCore = "4". So a plain Pkg.add("DelayDiffEq") resolves 6.1.0 + 4.11.0 and every DDE solve throws:

ERROR: MethodError: no method matching (OrdinaryDiffEqCore.DEOptions{...})(...)
  @ DelayDiffEq ~/.julia/packages/DelayDiffEq/wWvEW/src/solve.jl:341

The "closest candidate" Julia prints is the older 46-arg shim kept for DelayDiffEq ≤5.x. No shim exists for the intermediate 41-arg layout that 6.0.0–6.1.0 uses.

Layout boundary, checked against registry tree hashes:

	DEOptions
OrdinaryDiffEqCore 4.0.0 – 4.8.0	21 params / 41 fields
OrdinaryDiffEqCore 4.8.1 – 4.11.0	23 params / 43 fields
DelayDiffEq 6.0.0 – 6.1.0 (all registered 6.x)	constructs with 21 params / 41 args
DelayDiffEq on master	23 params / 43 args ✓

→ version 6.1.1, OrdinaryDiffEqCore = "4.8.1".

2. OrdinaryDiffEqDefault 2.4.1 has an off-by-one floor

It declares OrdinaryDiffEqCore = "4.8" but references OrdinaryDiffEqCore.AutoDePSpecialize, added in #3692 and first present in 4.8.1. Against 4.8.0 it fails to precompile:

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

This is what made a DelayDiffEq-only retrocap insufficient — capping DelayDiffEq at ≤4.8.0 leaves OrdinaryDiffEqDefault 2.4.1 in the resolution, which then needs ≥4.8.1. OrdinaryDiffEqTsit5 (≥2.1.1) and OrdinaryDiffEqRosenbrock (≥2.6.1) already declare 4.10.0; OrdinaryDiffEqDefault is the one that was missed.

→ version 2.4.2, OrdinaryDiffEqCore = "4.8.1".

Verification

Ran locally, not inferred:

• Reproduced the failure: fresh env, Pkg.add("DelayDiffEq") → 6.1.0 + OrdinaryDiffEqCore 4.11.0 → the MethodError above at solve.jl:341, matching a downstream StateSelection.jl report verbatim.
• Confirmed AutoDePSpecialize is absent from OrdinaryDiffEqCore 4.8.0 and present in 4.8.1 by scanning the sources of every installed 4.x.
• This branch: lib/DelayDiffEq at 6.1.1 with the 4.8.1 floor, developed against released OrdinaryDiffEqCore 4.11.0, solves a constant-lag DDEProblem with MethodOfSteps(Tsit5()) → SOLVED, retcode=Success.

I did not run the in-repo DelayDiffEq test suite for this change: the monorepo resolves sublibraries via [sources] path deps, so it is structurally insensitive to compat metadata and would exercise nothing here. The end-to-end check against registered packages above is the test that actually covers it.

Follow-up

Retroactive compat bounds are still wanted in General for the already-registered broken versions (DelayDiffEq 6.0.0–6.1.0 → "4.0.0 - 4.8.0", OrdinaryDiffEqDefault 2.4.1 → floor 4.8.1); handled separately.

Worth a separate discussion: DEOptions is documented public API and #3835 changed its field layout under a minor bump. The existing 46-arg shim shows source compatibility was the intent — the 41-arg path was simply overlooked. Adding a 41-arg/21-param shim to OrdinaryDiffEqCore would heal 6.0.0–6.1.0 without registry surgery.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KA1YU64UArbEbZrzF5Mvdz

[ChrisRackauckas-Claude]

CI status: every failure here is pre-existing on master

Checked each red workflow against the corresponding master run rather than assuming. This PR introduces no new failures.

Check	Result	Evidence it is not from this PR
CI (44 jobs)	failure	Failing job set is identical to master run 30535290549 — 44 vs 44, zero difference either direction
Sublibrary CI (18 jobs)	failure	All 18 die at instantiate on a SciMLBase constraint (see below), not an OrdinaryDiffEqCore one
Downgrade Sublibraries	failure	Identical 56-job failing set to master 30535290426; lib/DelayDiffEq and lib/OrdinaryDiffEqDefault are already failing there
Downgrade	failure	Identical failure signature to master, same stage
Documentation	failure	Same SciMLBase deadlock; failing on master for 4 consecutive runs
IntegrationTest	failure	Failing on master for 4 consecutive runs
format-check	failure	Runic flags lib/OrdinaryDiffEqCore/src/disco.jl, lib/OrdinaryDiffEqCore/src/integrators/controllers.jl, test/Integrators_I/disco_tests.jl — untouched here; this PR changes only two Project.toml files, which Runic does not check
Runic Suggestions, Spell Check, Benchmark this PR	success

Root cause of the master-wide breakage

#4059 raised the monorepo to SciMLBase 3.40, but the newest registered NonlinearSolveBase (2.38.0) caps SciMLBase at 3.37.0 - 3.39:

SciMLBase log:
 ├─restricted to versions 3.39.0 - 3   by OrdinaryDiffEq 7.2.0
 ├─restricted to versions 3.40.0 - 3   by OrdinaryDiffEqNonlinearSolve 2.6.0
 └─restricted by compatibility requirements with NonlinearSolveBase
       to versions: 3.19.0 - 3.39.1 — no versions left

SciMLBase would have to be both >= 3.40.0 and <= 3.39.1, so nothing in the repo can instantiate. This clears when a NonlinearSolveBase release allowing SciMLBase 3.40 is registered — General already carries a compat row for 2.38.1 - 2 at SciMLBase = "3.37.0 - 3", but 2.38.1 is not registered yet.

Why that does not affect confidence in this change

The compat fix was verified against released packages, independently of this repo's CI: lib/DelayDiffEq from this branch (6.1.1, floor OrdinaryDiffEqCore = "4.8.1"), developed against registered OrdinaryDiffEqCore 4.11.0, solves a constant-lag DDEProblem with MethodOfSteps(Tsit5()) → retcode=Success. The same setup on DelayDiffEq 6.1.0 reproduces the reported MethodError at solve.jl:341.

Since registration does not gate on CI, these two releases can go out without waiting for the NonlinearSolveBase release, which is what unblocks the downstream DDE failures.