One [compat] entry lists several majors.
| entry |
now |
suggested |
OrderedCollections |
1, 2 |
2 |
The smallest of the sweep. CTParser 0.9.0 already tightened ExaModels to 0.12 and CTBase
to 0.29, so this is the only leftover.
Note CTParser's test target carries CUDA, MadNLP and MadNLPGPU only transitively; if they
are ever declared here, the ecosystem values apply.
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.
One
[compat]entry lists several majors.OrderedCollections1, 22The smallest of the sweep. CTParser 0.9.0 already tightened
ExaModelsto0.12andCTBaseto
0.29, so this is the only leftover.Note CTParser's test target carries
CUDA,MadNLPandMadNLPGPUonly transitively; if theyare ever declared here, the ecosystem values apply.
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.