Two [compat] entries list several majors.
| entry |
now |
suggested |
JET |
0.9, 0.11, 0.12 |
0.12 |
OrderedCollections |
1, 2 |
2 |
No GPU stack here, so no interaction with the CUDSS trap. Included for completeness — the
ecosystem sweep should leave no repository behind.
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.JET0.9, 0.11, 0.120.12OrderedCollections1, 22No GPU stack here, so no interaction with the
CUDSStrap. Included for completeness — theecosystem sweep should leave no repository behind.
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.