Skip to content

Require operator-capable NonlinearSolveBase - #1079

Merged
ChrisRackauckas merged 1 commit into
SciML:masterfrom
ChrisRackauckas-Claude:codex/require-operator-base-floor
Jul 16, 2026
Merged

Require operator-capable NonlinearSolveBase#1079
ChrisRackauckas merged 1 commit into
SciML:masterfrom
ChrisRackauckas-Claude:codex/require-operator-base-floor

Conversation

@ChrisRackauckas-Claude

Copy link
Copy Markdown
Member

Summary

  • require NonlinearSolveBase 2.35, the first release with the operator-Jacobian support used by the current OrdinaryDiffEq nonlinear-solver integration
  • allow LinearSolve 4.3 as well as 5, matching the registered NonlinearSolveBase 2.35 dependency range
  • bump NonlinearSolve to 4.21.1 so downstream packages can require the corrected dependency floor

Root cause and impact

NonlinearSolve 4.21.0 allows NonlinearSolveBase 2.31, so downgrade resolution can select NonlinearSolveBase 2.33. OrdinaryDiffEq's operator-backed nonlinear solve then reaches similar(::SciMLOperators.MatrixOperator) and errors because that older base release does not use the operator-capable Jacobian path.

Requiring NonlinearSolveBase 2.35 keeps the operator handling available under downgrade resolution. Restoring LinearSolve 4.3 compatibility avoids forcing downstream packages onto LinearSolve 5 when the registered NonlinearSolveBase 2.35 release supports and passes with both major lines.

Ignore this PR until it has been reviewed by @ChrisRackauckas.

Validation

Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
@ChrisRackauckas
ChrisRackauckas marked this pull request as ready for review July 16, 2026 09:39
@ChrisRackauckas
ChrisRackauckas merged commit 60736b5 into SciML:master Jul 16, 2026
58 of 71 checks passed
ChrisRackauckas added a commit that referenced this pull request Jul 20, 2026
The source-tree sublibraries (NonlinearSolveBase, NonlinearSolveFirstOrder,
NonlinearSolveQuasiNewton) require LinearSolve 5, but the root Project.toml
floor was reverted to 4.3 in 60736b5 (#1079). The Downgrade workflow resolves
the root project at its compat floors with the sublibraries fixed as path
dependencies, so LinearSolve pinned at 4.3.0 conflicts with the sublibraries'
strict LinearSolve = "5" requirement and resolution fails before any test
runs.

Co-authored-by: ChrisRackauckas-Claude <accounts@chrisrackauckas.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants