Bump DiffEqBase / SciMLBase / OrdinaryDiffEq* compat to include v7/v3/v4#4467
Merged
ChrisRackauckas merged 2 commits intoSciML:masterfrom Apr 22, 2026
Merged
Conversation
Widens compat on both ModelingToolkit.jl (top-level) and lib/ModelingToolkitBase: ModelingToolkit 11.21.1 → 11.22.0: - DiffEqBase: "6.210.0" → "6.210.0, 7" - OrdinaryDiffEq: "6.82.0" → "6.82.0, 7" - OrdinaryDiffEqCore: "1.34.0, 2, 3" → "1.34.0, 2, 3, 4" - SciMLBase: "2.144.0" → "2.144.0, 3" ModelingToolkitBase 1.30.1 → 1.31.0: - DiffEqBase: "6.210.0" → "6.210.0, 7" - RecursiveArrayTools: "3.26" → "3.26, 4" - SciMLBase: "2.149.0" → "2.149.0, 3" (DiffEqCallbacks compat on MTKBase was already "2.16, 3, 4" — no change needed for the DiffEqCallbacks v4 line. ImplicitDiscreteSolve compat is "0.1.2, 1" and the monorepo's lib/ImplicitDiscreteSolve v1.11.0 satisfies it, no change needed. JumpProcesses v9.26.0 — per the in-flight SciML/JumpProcesses.jl#580 compat bump — satisfies the existing "9.23.0" floor.) Source grepped clean across `src/` and `ext/` (and `lib/ModelingToolkitBase/src`) for every symbol removed in the DiffEqBase v7 / SciMLBase v3 breaking notes: `u_modified!`, `has_destats`, `.destats`, `concrete_solve`, `fastpow`, `RECOMPILE_BY_DEFAULT`, `DEStats`, `QuadratureProblem`, `tuples()`/`intervals()`, standalone `DEAlgorithm`/`DEProblem`/`DESolution`. MTK uses the non-removed forms throughout (`AbstractSciMLProblem`, `AbstractDEProblem`, `ODEProblem`, etc.). Motivated by OrdinaryDiffEq.jl#3488 (v7 release branch). Even with DiffEqCallbacks / DiffEqNoiseProcess / the problem libraries / JumpProcesses compat widened, MTK and MTKBase were still pinning `DiffEqBase = "6.210.0"` and `SciMLBase = "2.x"`, which kept the `test (ModelingToolkit, …)` groups blocked at resolve time. KNOWN FOLLOWUP (not fixed by this PR): ModelingToolkitTearing (at JuliaComputing/StateSelection.jl, `lib/ModelingToolkitTearing`) pins `SciMLBase = "2.108"` and must be widened too before the MTK chain fully resolves against the v7 stack. That PR has to be opened against the JuliaComputing repo. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
Merged
4 tasks
Member
|
is this compat actually usable? I'm surprised that MTK CI would work with this. |
ChrisRackauckas
added a commit
to SciML/ParameterizedFunctions.jl
that referenced
this pull request
Apr 22, 2026
Widen `DiffEqBase = "6.144"` → `"6.144, 7"` so ParameterizedFunctions resolves alongside the v7 OrdinaryDiffEq stack (lib/DiffEqBase 7.0.0). Version bump 5.23.0 → 5.24.0. SciMLBase `"2.15, 3.0"` already covers v3. ModelingToolkit `"11"` covers the MTK 11.22.0 compat-widened release in flight (SciML/ModelingToolkit.jl#4467). Source uses `DiffEqBase.AbstractParameterizedFunction` (still defined in lib/DiffEqBase v7 under the `@static if isdefined(SciMLBase, :AbstractParameterizedFunction)` delegation/fallback block) and nothing else from DiffEqBase. None of the symbols removed in the v7 NEWS or SciMLBase v3 breaking notes appear in `src/`: `u_modified!`, `has_destats`, `.destats`, `concrete_solve`, `fastpow`, `RECOMPILE_BY_DEFAULT`, `DEStats`, `QuadratureProblem`, `tuples()`, `intervals()`, standalone `DEAlgorithm`/`DEProblem`/`DESolution`. Not a direct blocker of OrdinaryDiffEq's own CI (ParameterizedFunctions is a test-only dep of DiffEqDevTools, not a runtime dep) — included in the same v7-compat-widening set as DiffEqCallbacks#303, DiffEqNoiseProcess#271, DiffEqProblemLibrary#182, JumpProcesses#580, ModelingToolkit#4467, StateSelection#71 so downstream users can install ParameterizedFunctions together with the v7 stack. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
Member
|
This unblocks the OrdinaryDiffEq downstream MTK tests which then serve as the main barrier, since yes none of this can be used until solvers compatible with these versions are released. |
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>
This was referenced Apr 22, 2026
Open
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
3 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 compat on both ModelingToolkit.jl and
lib/ModelingToolkitBaseso MTK resolves alongside the in-development v7 OrdinaryDiffEq stack / DiffEqBase 7 / SciMLBase 3 / OrdinaryDiffEqCore 4.ModelingToolkit 11.21.1 → 11.22.0:
DiffEqBase"6.210.0""6.210.0, 7"OrdinaryDiffEq"6.82.0""6.82.0, 7"OrdinaryDiffEqCore"1.34.0, 2, 3""1.34.0, 2, 3, 4"SciMLBase"2.144.0""2.144.0, 3"ModelingToolkitBase 1.30.1 → 1.31.0:
DiffEqBase"6.210.0""6.210.0, 7"RecursiveArrayTools"3.26""3.26, 4"SciMLBase"2.149.0""2.149.0, 3"Already-OK entries left alone:
DiffEqCallbacks = "2.16, 3, 4"(on MTKBase) — v4 already covered.ImplicitDiscreteSolve = "0.1.2, 1"— the monorepo'slib/ImplicitDiscreteSolvev1.11.0 satisfies it.JumpProcesses = "9.23.0"— Bump DiffEqBase / OrdinaryDiffEq / OrdinaryDiffEqCore compat to include v7/v4 JumpProcesses.jl#580 ships 9.26.0 with v7 compat, still ≥ floor.OrdinaryDiffEqRosenbrock = "1"/OrdinaryDiffEqDefault = "1.2"/OrdinaryDiffEqBDF = "1"/OrdinaryDiffEqNonlinearSolve = "1.5.0"— monorepo sublibs are still v1, so their existing caps work. Once those sublibs v-bump alongside the OrdinaryDiffEq v7 release they'll need a follow-up widening.Motivation
On SciML/OrdinaryDiffEq.jl#3488 (v7 release branch), the
test (ModelingToolkit, …)matrix fails at resolve time with cascadingUnsatisfiable requirements detected for package …errors terminating at MTK / MTKBase's DiffEqBase 6 pin. After widening the upstream blockers (DiffEqCallbacks.jl#303, DiffEqNoiseProcess.jl#271, DiffEqProblemLibrary.jl#182, JumpProcesses.jl#580), MTK / MTKBase are the last SciML-org pins in the chain.Why this is source-level safe
Grepped
src/,ext/, andlib/ModelingToolkitBase/src/for every symbol removed in the v7 NEWS or SciMLBase v3 breaking notes:u_modified!,has_destats,.destats,concrete_solve,fastpow,RECOMPILE_BY_DEFAULT,DEStats,QuadratureProblem,tuples()/intervals(), and standaloneDEAlgorithm/DEProblem/DESolution(excluding theAbstract…forms, which are kept). Zero matches for any of the removed standalone names. MTK consistently uses the non-removed API forms —AbstractSciMLProblem,AbstractDEProblem, concreteODEProblem, etc.KNOWN FOLLOWUP — not fixed by this PR
ModelingToolkitTearingatJuliaComputing/StateSelection.jl#lib/ModelingToolkitTearingstill pinsSciMLBase = "2.108". Oncelib/DiffEqBasev7 is in the resolver environment, the failure cascades past MTK/MTKBase to:That widening has to happen in
JuliaComputing/StateSelection.jl(and probably inStateSelectionitself, which lives in the same monorepo). I can't open a PR over there without explicit permission — flagging here so a maintainer with access can pick it up.Test plan
lib/DiffEqBasev7.0.0 up to the ModelingToolkitTearing SciMLBase cap (the last remaining blocker, noted above).test (ModelingToolkit, …)once this + the ModelingToolkitTearing bump are registered.Co-Authored-By: Chris Rackauckas accounts@chrisrackauckas.com