Bump DiffEqBase / OrdinaryDiffEq / OrdinaryDiffEqCore compat to include v7/v4#580
Merged
ChrisRackauckas merged 2 commits intoSciML:masterfrom Apr 22, 2026
Merged
Conversation
…de v7/v4 Widens: - DiffEqBase: "6.192" → "6.192, 7" - OrdinaryDiffEq: "6" → "6, 7" - OrdinaryDiffEqCore: "3" → "3, 4" so JumpProcesses can be installed alongside the v7 release line of the OrdinaryDiffEq stack (lib/DiffEqBase 7.0.0 + lib/OrdinaryDiffEqCore 4.0.0). Version bump 9.25.1 → 9.26.0. Source is already v7/v3-compatible. The `u_modified!` renames were landed in SciML#579 "Prepare source for SciMLBase v3 and widen compat": - `SSA_stepper.jl` already defines `DiffEqBase.u_modified!(::SSAIntegrator, ::Bool)` and, under a `@static if isdefined(SciMLBase, :derivative_discontinuity!)` guard, also defines `SciMLBase.derivative_discontinuity!(::SSAIntegrator, ::Bool)` so SciMLBase v3's callback machinery (which calls the new name) dispatches correctly. - The generic `u_modified!(integrator, true/false)` call sites in `variable_rate.jl` / `aggregators/ssajump.jl` / `aggregators/coevolve.jl` continue to resolve via the SciMLBase v3 `@deprecate u_modified!(i, bool) derivative_discontinuity!(i, bool)` — the function still exists on v3, it just forwards to the renamed name (scheduled removal 2028 per the SciMLBase comment). No runtime breakage; may emit deprecation warnings that can be cleaned up in a follow-up if desired. Motivated by OrdinaryDiffEq.jl#3488 (v7 release branch) where the MTK / StochasticDiffEq-monorepo test path pulls JumpProcesses in transitively (via ModelingToolkitBase and StochasticDiffEqImplicit), and resolution failed with "Unsatisfiable requirements detected for package JumpProcesses … restricted by compatibility requirements with DiffEqBase [2b5f629d] to versions: uninstalled" once `lib/DiffEqBase` v7.0.0 was fixed into the environment. Test deps (`StochasticDiffEq = "6.82"`) intentionally left alone — the monorepo's StochasticDiffEq v6.102.0 satisfies it, and StochasticDiffEq is only a test dep on JumpProcesses (so the cap doesn't propagate to downstream consumers). Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
4 tasks
Merged
4 tasks
ChrisRackauckas
added a commit
to SciML/ModelingToolkit.jl
that referenced
this pull request
Apr 22, 2026
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>
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
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 compat so JumpProcesses resolves alongside the in-development v7 OrdinaryDiffEq stack (
lib/DiffEqBase7.0.0 +lib/OrdinaryDiffEqCore4.0.0 in the OrdinaryDiffEq monorepo):DiffEqBase: "6.192"→"6.192, 7"OrdinaryDiffEq: "6"→"6, 7"OrdinaryDiffEqCore: "3"→"3, 4"Version bump 9.25.1 → 9.26.0.
Motivation
On SciML/OrdinaryDiffEq.jl#3488 (v7 release branch), the
test (ModelingToolkit, …)matrix and various indirect paths fail at resolve time. Even after DiffEqCallbacks.jl#303 + DiffEqNoiseProcess.jl#271 + the problem-library bumps, resolution still trips over JumpProcesses, which is pulled in transitively viaModelingToolkitBase→JumpProcessesand viaStochasticDiffEqImplicit→JumpProcesses:This widening unblocks that edge.
Why this is source-level safe
The SciMLBase v3 / DiffEqBase v7 rename work was already landed in #579 ("Prepare source for SciMLBase v3 and widen compat"):
src/SSA_stepper.jldefines bothDiffEqBase.u_modified!(::SSAIntegrator, ::Bool)and, under@static if isdefined(SciMLBase, :derivative_discontinuity!),SciMLBase.derivative_discontinuity!(::SSAIntegrator, ::Bool). So SciMLBase v3's callback machinery (which now calls the renamedderivative_discontinuity!) dispatches correctly to the SSA integrator path.u_modified!(integrator, true/false)call sites insrc/variable_rate.jl/src/aggregators/ssajump.jl/src/aggregators/coevolve.jlstill resolve on v3: SciMLBase keepsu_modified!as@deprecate u_modified!(i::DEIntegrator, bool) derivative_discontinuity!(i, bool)(scheduled removal 2028, per the SciMLBase comment). Runtime behavior is unchanged; expect only deprecation warnings, which can be cleaned up as a follow-up by mechanically swapping the remaining generic call sites toderivative_discontinuity!.has_destats,.destats,concrete_solve,fastpow,RECOMPILE_BY_DEFAULT,DEStats,QuadratureProblem,tuples()/intervals(), standaloneDEAlgorithm/DEProblem/DESolution).Test plan
u_modified!case (covered by the existing v3 guard + the scheduled-2028 SciMLBase deprecate forwarder).Unsatisfiable requirements detected for package JumpProcessesshould disappear from MTK / Stoch-Impl test groups once this is registered.Intentionally out of scope
[compat] StochasticDiffEq = "6.82"left alone. It's a test dep of JumpProcesses; doesn't propagate. The monorepo StochasticDiffEq v6.102.0 still satisfies the pin.u_modified!→derivative_discontinuity!sweep invariable_rate.jl/aggregators/*.jl— belongs in a follow-up once the compat widening is in users' hands.Co-Authored-By: Chris Rackauckas accounts@chrisrackauckas.com