Two [compat] entries list several majors.
| entry |
now |
suggested |
ForwardDiff |
0.10, 1 |
1 |
JET |
0.9, 0.11, 0.12 |
0.12 |
CTBase sits under everything, so its ForwardDiff bound is the one that would keep 0.10
reachable for the whole ecosystem even after the leaves tighten. Worth doing first, or at least
not last.
Why now
The ecosystem decision (2026-08-26) is to keep only the newest major where it resolves. The
trigger was MadNLPGPU = "0.8, 0.10", which spans a behaviour change: up to 0.8, CUDSS was a
hard dependency, so using MadNLPGPU armed the GPU extension by accident; from 0.9 it is a
weak dependency and must be loaded explicitly. Keeping both in range forces the
documentation to describe two worlds, and only one of them is ever resolved.
The one trap — do not harmonise CUDSS across the ecosystem
CUDSS 0.8.0 requires LinearSolve ≤ 2.28, while NonlinearSolve 4 requires
LinearSolve ≥ 3.48. So the right bound differs per repository, measured 2026-08-26:
| repository |
has NonlinearSolve |
CUDSS = "0.8" |
| CTSolvers, CTDirect |
no |
resolves — CUDA 6.2.0, MadNLPGPU 0.10.2, no LinearSolve at all |
| OptimalControl |
yes (4.28.0) |
unsatisfiable — must stay "0.7" |
That divergence is correct. Do not "fix" it into a single shared value.
Related
- Ecosystem plan:
OptimalControl.jl/.reports/campaign/F-compat-tighten.md
- Decision record:
OptimalControl.jl/.reports/campaign/decisions.md §1
- CTSolvers#216 — the GPU
ExtensionError names MadNLPGPU when the missing trigger is CUDSS. Tightening to 0.10
makes that message wrong 100% of the time instead of sometimes, so the two changes belong
together.
Two
[compat]entries list several majors.ForwardDiff0.10, 11JET0.9, 0.11, 0.120.12CTBase sits under everything, so its
ForwardDiffbound is the one that would keep0.10reachable for the whole ecosystem even after the leaves tighten. Worth doing first, or at least
not last.
Why now
The ecosystem decision (2026-08-26) is to keep only the newest major where it resolves. The
trigger was
MadNLPGPU = "0.8, 0.10", which spans a behaviour change: up to 0.8,CUDSSwas ahard dependency, so
using MadNLPGPUarmed the GPU extension by accident; from 0.9 it is aweak dependency and must be loaded explicitly. Keeping both in range forces the
documentation to describe two worlds, and only one of them is ever resolved.
The one trap — do not harmonise
CUDSSacross the ecosystemCUDSS 0.8.0requiresLinearSolve ≤ 2.28, whileNonlinearSolve 4requiresLinearSolve ≥ 3.48. So the right bound differs per repository, measured 2026-08-26:NonlinearSolveCUDSS = "0.8""0.7"That divergence is correct. Do not "fix" it into a single shared value.
Related
OptimalControl.jl/.reports/campaign/F-compat-tighten.mdOptimalControl.jl/.reports/campaign/decisions.md§1ExtensionErrornamesMadNLPGPUwhen the missing trigger isCUDSS. Tightening to 0.10makes that message wrong 100% of the time instead of sometimes, so the two changes belong
together.