Repository navigation
Retroactively cap DelayDiffEq at OrdinaryDiffEqCore 4.8.0 - #162781
ChrisRackauckas merged 1 commit into
Conversation
|
Cross-link from the clean Julia 1.10 ModelingToolkit initialization audit: after fixing the two independent |
|
This is an extremely time sensitive simple retrocap but the people I am pinging are not responding today so I am going to merge as we really need to make sure we don't leave people hanging on this thing. |
|
This pull request has been inactive for 30 days and will be automatically closed 7 days from now. If this pull request should not be closed, please either (1) fix the AutoMerge issues and re-trigger Registrator, which will automatically update the pull request, or (2) post a comment explaining why you would like this pull request to be manually merged. It would also be helpful if you could post a message in the |
DelayDiffEq 6.0.0 through 6.1.0 use the pre-limiter DEOptions constructor. OrdinaryDiffEqCore 4.8.1 is the first release with the incompatible limiter-aware layout, so keep those DelayDiffEq releases on Core 4.8.0 or earlier. DelayDiffEq 6.1.1 already floors at Core 4.8.1 and 6.1.2+ at 4.12.0, so later releases are unaffected. Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Agent-Harness: Claude Code Agent-Model: claude-fable-5 Agent-Session: https://claude.ai/code/session_01YP75PszwM7qriCJho8QNQC
0eccbe5 to
42af7e6
Compare
|
Rebased onto current master (42af7e6). The branch now carries a single one-line change: Please keep this open for manual merge: it is a retroactive cap, so Registrator cannot regenerate it. 🤖 Rebased by Claude Code (model: claude-fable-5) — https://claude.ai/code/session_01YP75PszwM7qriCJho8QNQC |
Summary
Why
Those DelayDiffEq releases call the pre-limiter
DEOptionsconstructor. OrdinaryDiffEqCore 4.8.1 introduced the incompatible limiter-aware layout, so the current registry can resolve a combination that fails with aMethodError.Since this was opened, DelayDiffEq 6.1.1 (Core floor
4.8.1) and 6.1.2 / 6.2.0 (Core floor4.12.0) were registered, so the affected range is exactly6 - 6.1.0and the cap slots into the["6 - 6.1.0"]table that master already has. The previously stacked OrdinaryDiffEqDefault change (#162780) landed via #162878 and is no longer part of this PR.Verification
Pkg.Registry.compat_infooverD/DelayDiffEqon master vs. this branch:The original run reproduced the
DEOptionsMethodErrorwith unmodified registry metadata and solved the representative delayed problem with the cap applied (see the earlier discussion above).Please ignore this draft until it has been reviewed by @ChrisRackauckas.
🤖 Generated with Claude Code (model: claude-fable-5)
https://claude.ai/code/session_01YP75PszwM7qriCJho8QNQC