Patch v9.26.1: tighten OrdinaryDiffEqCore lower bound to 3.17#583
Closed
ChrisRackauckas-Claude wants to merge 1 commit into
Closed
Conversation
… to 3.17 JumpProcessesOrdinaryDiffEqCoreExt imports `StochasticDiffEqAlgorithm` and `StochasticDiffEqRODEAlgorithm` from `OrdinaryDiffEqCore`, but those abstract types were only added in OrdinaryDiffEqCore v3.17.0. The current compat `"3, 4"` lets the resolver pick OrdinaryDiffEqCore v3.0–v3.16 — anything before v3.17 — and the extension precompile then dies with `UndefVarError: StochasticDiffEqAlgorithm`. Hit in the wild whenever JumpProcesses ≥ v9.24 is pulled in alongside the OrdinaryDiffEq v6 / ModelingToolkit v9 era, which transitively pins OrdinaryDiffEqCore down to v3.1.x. Reproduced in SBMLToolkit#199 and SBMLToolkitTestSuite#63. Bumping the lower bound to 3.17 ensures only versions that actually export those symbols can resolve. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
ChrisRackauckas-Claude
pushed a commit
to ChrisRackauckas-Claude/JumpProcesses.jl
that referenced
this pull request
Apr 27, 2026
…op pre-v7 ecosystem (v10.0.0) PR SciML#581's CI surfaced that the partial SciMLBase v3 migration in PR SciML#579 left `SSAIntegrator.u_modified::Bool` named the old way. DiffEqBase v7's `initialize!(...)` accesses `integrator.derivative_discontinuity` as a struct field directly (not via a method), so a `getproperty` shim or method override can't paper over it — hence: LoadError: FieldError: type JumpProcesses.SSAIntegrator has no field `derivative_discontinuity`, available fields: ..., `u_modified`, ... This commit finishes the rename: • SSAIntegrator field `u_modified` → `derivative_discontinuity` • All `integrator.u_modified` reads/writes in SSA_stepper.jl updated • Replace `DiffEqBase.u_modified!` method with the canonical `SciMLBase.derivative_discontinuity!` method, dropping the `@static if isdefined(SciMLBase, :derivative_discontinuity!)` guard (no longer needed with SciMLBase v3 lower bound) • Internal `u_modified!(integrator, ...)` calls in variable_rate.jl, aggregators/coevolve.jl, aggregators/ssajump.jl rewritten to `derivative_discontinuity!(integrator, ...)` • `using ... u_modified!` → `using SciMLBase: derivative_discontinuity!` Renaming the field is a breaking ABI change for any code that touched `integrator.u_modified` directly, so this also drops the pre-v7 ecosystem support entirely (DiffEqBase v6 callbacks still expect the old field name and would break if we dragged the v6 lower bound along): • DiffEqBase: `"6.192, 7"` → `"7"` • OrdinaryDiffEq: `"6, 7"` → `"7"` • OrdinaryDiffEqCore: `"3, 4"` → `"4"` • OrdinaryDiffEqFunctionMap: `"1, 2"` → `"2"` • RecursiveArrayTools: `"3.35, 4"` → `"4"` • SciMLBase: `"2.115, 3.1"` → `"3.1"` • StochasticDiffEq: `"6.82, 7"` → `"7"` Bumps version 9.26.0 → 10.0.0. The v9 line stays available for users still on the OrdinaryDiffEq v6 / SciMLBase v2 era; the patch v9.26.1 (in flight at SciML#583) handles the OrdinaryDiffEqCore lower-bound bug there. docs/Project.toml and docs/src/assets/Project.toml updated to drop v6 support to match. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
ChrisRackauckas-Claude
pushed a commit
to ChrisRackauckas-Claude/JumpProcesses.jl
that referenced
this pull request
Apr 27, 2026
… to v9.27.0 PR SciML#581's CI surfaced that DiffEqBase v7 / SciMLBase v3 callbacks access `integrator.derivative_discontinuity` as a struct field directly (not via a method), so the v6-era field name `u_modified` blew up at runtime: LoadError: FieldError: type JumpProcesses.SSAIntegrator has no field `derivative_discontinuity`, available fields: ..., `u_modified`, ... Renaming the field would be a breaking ABI change (and would force v7-only compat, since DiffEqBase v6 callbacks still read `integrator.u_modified`). Instead, this commit overrides `Base.getproperty` / `Base.setproperty!` / `Base.propertynames` on `SSAIntegrator` to alias `:derivative_discontinuity` onto the existing `:u_modified` field. Both names resolve to the same storage, so v6 and v7 callback code both keep working unchanged. Internal `u_modified!(integrator, ...)` calls and the `DiffEqBase.u_modified!` / `SciMLBase.derivative_discontinuity!` method definitions are left in place — they continue to dispatch correctly under both ecosystems (the SciMLBase v3 `@deprecate u_modified! → derivative_discontinuity!` alias is bypassed by JumpProcesses' more specific method). Also tightens the existing widening from `OrdinaryDiffEqCore = "3, 4"` to `"3.17, 4"` — the imported `StochasticDiffEqAlgorithm` / `StochasticDiffEqRODEAlgorithm` symbols only exist from v3.17+, and allowing v3.0–v3.16 lets the resolver pick a version that breaks the extension precompile (same root cause being patched on master via SciML#583). Bumps version 9.26.0 → 9.27.0 (minor, fully backwards compatible). Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
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
Patch release fixing a downstream-breaking bug introduced in JumpProcesses v9.24.0.
JumpProcessesOrdinaryDiffEqCoreExt(added in v9.24.0, commit 31ca00b) importsStochasticDiffEqAlgorithmandStochasticDiffEqRODEAlgorithmfromOrdinaryDiffEqCore, but those abstract types were only added in OrdinaryDiffEqCore v3.17.0. The current compatOrdinaryDiffEqCore = "3, 4"lets the resolver pick anything from v3.0.x onward — including v3.0–v3.16 which don't define the symbols.When a downstream package pins JumpProcesses ≥ v9.24 alongside an OrdinaryDiffEq-v6 / ModelingToolkit-v9 stack,
OrdinaryDiffEqCoregets transitively downgraded to v3.1.x and the extension precompile dies:Reproduced in the wild on:
OrdinaryDiffEqCorev3.33.1 → v3.1.0)Changes
versionto9.26.1OrdinaryDiffEqCorecompat from"3, 4"to"3.17, 4"so the resolver can only pick versions that actually define the imported symbols.Companion PR
A retroactive registry fix is open at JuliaRegistries/General to apply the same compat tightening to already-released versions (v9.24.0, v9.25.0, v9.25.1, v9.26.0) so existing-version resolves stop pulling in the broken combination.
Test plan
JumpProcessesOrdinaryDiffEqCoreExtshould disappear because the resolver can no longer pick v3.1.x).