Bump DiffEqBase compat to include v7 across problem-library sublibs#182
Merged
ChrisRackauckas merged 1 commit intoSciML:masterfrom Apr 22, 2026
Merged
Conversation
Add DiffEqBase 7.0.0 (OrdinaryDiffEq v7 release; currently at `lib/DiffEqBase` in the OrdinaryDiffEq monorepo) to the compat of every sublibrary that depends on DiffEqBase, and widen SDEProblemLibrary's SciMLBase compat to include v3 as well. Version bumps (non-breaking compat widening): - ODEProblemLibrary 1.4.0 → 1.5.0 (DiffEqBase "6" → "6, 7") - DDEProblemLibrary 0.1.4 → 0.1.5 (DiffEqBase "6" → "6, 7") - SDEProblemLibrary 1.1.1 → 1.2.0 (DiffEqBase "6" → "6, 7"; SciMLBase "2.0.1" → "2.0.1, 3") - BVProblemLibrary 0.1.8 → 0.1.9 (DiffEqBase "6" → "6, 7") - DAEProblemLibrary 0.1.2 → 0.1.3 (DiffEqBase "6" → "6, 7") JumpProblemLibrary is intentionally NOT bumped here: it also pins Catalyst to "15", and widening it properly is tangled with a Catalyst bump that is out of scope for this PR. NonlinearProblemLibrary has no DiffEqBase dep and is untouched. Every sublibrary grepped clean for every symbol removed in the v7 NEWS (`u_modified!`, `has_destats`, `concrete_solve`, `fastpow`, `RECOMPILE_BY_DEFAULT`, `DEStats`, `QuadratureProblem`, `.destats`, `tuples()`/`intervals()`). These are problem-definition libraries — they define `ODEProblem`/`DDEProblem`/`SDEProblem`/`BVProblem`/`DAEProblem` instances and nothing else — so their DiffEqBase surface is tiny and entirely stable across the v7 rename. Motivated by OrdinaryDiffEq.jl#3488 (the v7 release branch), where `test (InterfaceI..V, …)` and similar run against the registered ODEProblemLibrary and fail at resolve time with `Unsatisfiable requirements detected for package ODEProblemLibrary … restricted by compatibility requirements with DiffEqBase to versions: uninstalled`. Same class of failure for the DDE/SDE/BV/DAE libs when pulled in transitively via DiffEqDevTools test deps. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
Merged
4 tasks
ChrisRackauckas
added a commit
to SciML/Sundials.jl
that referenced
this pull request
Apr 22, 2026
Widen `DiffEqBase = "6.217"` → `"6.217, 7"` so Sundials resolves alongside the in-development DiffEqBase 7.0.0 (lib/DiffEqBase in the OrdinaryDiffEq v7 monorepo). Version bump 5.2.0 → 5.3.0. Already-OK: SciMLBase "2.119.0, 3", DiffEqCallbacks "4". DiffEqCallbacks 4.x covers the 4.16 in SciML/DiffEqCallbacks.jl#303; ODEProblemLibrary "1" covers the 1.5 in SciML/DiffEqProblemLibrary.jl#182; DAEProblemLibrary "0.1" covers the 0.1.3 in the same PR; ModelingToolkit "11" covers the 11.22 in SciML/ModelingToolkit.jl#4467. Source is v3/v7-compatible: - `DiffEqBase.u_modified!(integrator::AbstractSundialsIntegrator, bool)` at `src/common_interface/integrator_utils.jl:215` continues to work: SciMLBase v3 keeps `u_modified!` as `@deprecate u_modified!(i, bool) derivative_discontinuity!(i, bool)` (scheduled removal 2028), so adding a method to it is still valid. Will emit deprecation warnings on v3 that can be cleaned up in a follow-up by swapping to `SciMLBase.derivative_discontinuity!`. - `SciMLBase.DEStats(0)` at three sites in `src/common_interface/solve.jl` (lines 469, 1054, 1461) is fine: `DEStats` was NOT removed in SciMLBase v3; only the `DiffEqBase.DEStats` re-export was removed. The `SciMLBase.DEStats` struct itself is still exported. None of the other removed v7 / SciMLBase v3 symbols (`has_destats`, `.destats`, `concrete_solve`, `fastpow`, `RECOMPILE_BY_DEFAULT`, `QuadratureProblem`, `tuples()`/`intervals()`, standalone `DEAlgorithm`/`DEProblem`/`DESolution`) appear in `src/` or `ext/`. Motivated by the OrdinaryDiffEq.jl v7 release branch (#3488) — any downstream user pulling both Sundials and the v7 OrdinaryDiffEq stack currently gets an unsatisfiable requirements error on DiffEqBase. Not a direct blocker of OrdinaryDiffEq's own CI (Sundials isn't a test dep), but part of the same v7-compat-widening set as DiffEqCallbacks#303, DiffEqNoiseProcess#271, DiffEqProblemLibrary#182, JumpProcesses#580, ModelingToolkit#4467, StateSelection#71, ParameterizedFunctions#151, SciMLSensitivity#1431. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Widen
DiffEqBase = "6"→DiffEqBase = "6, 7"on every sublibrary that depends on DiffEqBase, and widen SDEProblemLibrary'sSciMLBase = "2.0.1"→"2.0.1, 3"as well. This lets the sublibs be installed alongside the in-development DiffEqBase 7.0.0 / SciMLBase 3 (shipped with OrdinaryDiffEq.jl v7, currently atlib/DiffEqBasein the OrdinaryDiffEq monorepo).Per-sublib version bumps (non-breaking compat widening):
Out of scope:
Catalyst = "15", which is two majors behind the current Catalyst 16.1.1. Widening it properly needs a Catalyst bump too, which belongs in its own PR.Motivation
On SciML/OrdinaryDiffEq.jl#3488 (the v7 release branch), the
test (Interface{I..V}, …)matrix and several other test groups fail at resolve time with:The
lib/DiffEqBasev7 from the OrdinaryDiffEq monorepo is dev'd into every test env, while ODEProblemLibrary (and the other problem libs pulled in transitively through DiffEqDevTools test deps) come from the General registry with theirDiffEqBase = "6"cap. This PR widens that cap.Why this is source-level safe
These are problem-definition libraries. Each one does nothing but construct
ODEProblem/DDEProblem/SDEProblem/BVProblem/DAEProbleminstances and expose them as module-level globals for downstream solver tests. Their DiffEqBase surface is tiny and entirely stable across the v7 rename:src/for every symbol removed in the v7 NEWS (u_modified!,has_destats,concrete_solve,fastpow,RECOMPILE_BY_DEFAULT,DEStats,QuadratureProblem,.destats,DEAlgorithm/DEProblem/DESolutionas standalone names,tuples()/intervals()) → zero matches across all five bumped sublibs.importoruseany symbol that was removed or renamed; the problem-type constructors (ODEProblem, etc.) are re-exported from both DiffEqBase 6 and 7 unchanged.Test plan
Unsatisfiable requirements detected for package ODEProblemLibrary(and sibling) lines should disappear once these are registered.Co-Authored-By: Chris Rackauckas accounts@chrisrackauckas.com