Skip to content

Restore root LinearSolve 5 floor - #1087

Closed
ChrisRackauckas-Claude wants to merge 1 commit into
SciML:masterfrom
ChrisRackauckas-Claude:agent/restore-root-linearsolve-floor
Closed

Restore root LinearSolve 5 floor#1087
ChrisRackauckas-Claude wants to merge 1 commit into
SciML:masterfrom
ChrisRackauckas-Claude:agent/restore-root-linearsolve-floor

Conversation

@ChrisRackauckas-Claude

Copy link
Copy Markdown
Member

Important

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

Summary

  • Restore the root LinearSolve compatibility floor to version 5, matching the current in-tree Base, FirstOrder, and QuasiNewton source packages.
  • Bump the root package patch version from 4.21.1 to 4.21.2 so the compatibility correction is releasable.

Root cause

PR #1070 established that the current source-tree caches require the LinearSolve 5 interface: LinearSolve 4.3 fails when the local FirstOrder and QuasiNewton packages use callable LinearSolveJLCache behavior. PR #1079 subsequently broadened only the root compatibility entry from 5 back to 4.3, 5, while the in-tree NonlinearSolveQuasiNewton 1.14.1 project still requires LinearSolve 5.

The deployed downgrade action therefore selected and explicitly pinned LinearSolve 4.3.0 from the root floor. Pkg.test(...; allow_reresolve=false) then combined that manifest with the in-tree source packages and failed before loading test code:

LinearSolve possible versions: 0.1.0-5.0.0
restricted to version 5 by NonlinearSolveQuasiNewton 1.14.1
restricted to version 4.3.0 by an explicit requirement — no versions left

This is the failure in PR #1061's unrelated downgrade job 87701889361 (run 29522250552). The exact same failure reproduces on clean upstream master at 60736b5, so this PR contains no #1061 code.

A formal bisect over the relevant clean-master range reported:

60736b5b6a30a42001c1938647362ef138b1c6a7 is the first bad commit

The good midpoint, cbabebe8 (#1075), selected LinearSolve 5.0.0 and reached the Core test body. The first bad commit is 60736b5 (#1079), whose root-only compatibility change reopened the incompatible 4.3 endpoint.

Validation

All Julia validation used Julia 1.10.11 and workspace-local depots.

  • The exact deployed julia-actions/julia-downgrade-compat@v2 implementation (fab1defb76df9fd672f63c94df73ce131d32e134) completed on the final diff with the workflow-derived stdlib and [sources] skip list, mode deps, Julia floor 1, and Mooncake no-promote setting.

  • The resulting manifest contains NonlinearSolve 4.21.2 and LinearSolve 5.0.0.

  • The exact CI test invocation reached and ran Core tests instead of failing in dependency resolution:

    Pkg.test(;
        coverage = true,
        julia_args = ["--check-bounds=yes", "--compiled-modules=yes", "--depwarn=yes"],
        force_latest_compatible_version = false,
        allow_reresolve = false,
    )
  • Core is not green on clean master. The final diff and the good bisect control both reach the same independently documented Broyden baseline: 94 passed, 1 failed, 1 errored, 19 broken. The failure is Generalized Rosenbrock algorithm 4; the error is the Brown algorithm-4 unexpected pass. These are tracked in Master CI red since 2026-07-12: "23 Test Problems: Broyden" alg #4 broken-list mismatch, bisected to #1039 (merged via cancelled CI run) #1083 and Brown bad-Broyden broken test is environment-sensitive #1056. This PR does not skip, silence, loosen, or otherwise modify either test.

  • Runic 1.7.0 passed all 373 tracked Julia files.

  • Project.toml parsing and assertions for version 4.21.2 and LinearSolve = "5" passed.

  • git diff --check passed.

The existing root downgrade workflow provides regression coverage for this compatibility floor; no test source was changed.

Investigation process

I inspected the failing Actions job and exact reusable workflow inputs, reproduced the clean-master resolver failure with the deployed action SHA, reviewed prior fixes #1059, #1070, #1075, and #1079, ran a formal git bisect, compared the good midpoint's full Core result with the patched result, searched open PRs and issues for a duplicate fix, and validated the smallest source-tree-compatible correction. The open #1086 changes only the Base sublibrary version and does not overlap this root change.

Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
@ChrisRackauckas-Claude

Copy link
Copy Markdown
Member Author

Interim CI audit for head 6f18c93571973ef43f88867ca4aaa985366075f6:

@ChrisRackauckas-Claude

Copy link
Copy Markdown
Member Author

Closing as superseded by merged #1095. That PR landed the same required root LinearSolve = "5" correction; current master is version 4.22.0 and both its exact-current root and sublibrary downgrade workflows are green: https://github.com/SciML/NonlinearSolve.jl/actions/runs/29762728296 and https://github.com/SciML/NonlinearSolve.jl/actions/runs/29762728169. No unique source or test change remains in this older draft.

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