I've hit two things around dependency version bumps that I can't fully explain, so I'm writing down what I saw in case it points at something worth fixing.
The first: I bump a dependency's pinned version in corral.json and run corral fetch (through a project's make), and the existing _corral/<dep>/ checkout stays on the old version. Nothing errors. The build and the tests run green against the old code, so there's no sign anything is off until you go look at what's actually in _corral. Deleting lock.json on its own doesn't force the update. What does is a full clean — rm -rf _corral (or make clean) — so corral fetch re-clones from scratch.
The second is stranger, and I only saw it in a graph with several dependencies. Even after a full rm -rf _corral _repos && corral fetch, corral sometimes resolves a transitive dependency to a lower version than anything in the graph asks for. I bumped stallion, courier, and mare to versions that all require lori 0.16.1, and corral kept resolving lori 0.15.1, with 0.16.1 as the only lori constraint anywhere in the graph. It isn't deterministic: re-running the exact same rm -rf _corral _repos && corral fetch flips it to 0.16.1 after a retry or two. With just the one bumped dependency in a repo, corral resolved it correctly on the first try, so it seems to take a several-dependency graph to show up. corral clean doesn't clear _repos, which is why the rm -rf includes it.
Both of these mean you can build and test green while linking the wrong version of a dependency, and CI runs the same corral, so CI can land on the wrong version too.
I saw this with corral 0.9.0 and haven't gone back to check whether it still reproduces on 0.9.2.
I've hit two things around dependency version bumps that I can't fully explain, so I'm writing down what I saw in case it points at something worth fixing.
The first: I bump a dependency's pinned version in
corral.jsonand runcorral fetch(through a project'smake), and the existing_corral/<dep>/checkout stays on the old version. Nothing errors. The build and the tests run green against the old code, so there's no sign anything is off until you go look at what's actually in_corral. Deletinglock.jsonon its own doesn't force the update. What does is a full clean —rm -rf _corral(ormake clean) — socorral fetchre-clones from scratch.The second is stranger, and I only saw it in a graph with several dependencies. Even after a full
rm -rf _corral _repos && corral fetch, corral sometimes resolves a transitive dependency to a lower version than anything in the graph asks for. I bumped stallion, courier, and mare to versions that all requirelori 0.16.1, and corral kept resolvinglori 0.15.1, with0.16.1as the only lori constraint anywhere in the graph. It isn't deterministic: re-running the exact samerm -rf _corral _repos && corral fetchflips it to0.16.1after a retry or two. With just the one bumped dependency in a repo, corral resolved it correctly on the first try, so it seems to take a several-dependency graph to show up.corral cleandoesn't clear_repos, which is why therm -rfincludes it.Both of these mean you can build and test green while linking the wrong version of a dependency, and CI runs the same corral, so CI can land on the wrong version too.
I saw this with corral 0.9.0 and haven't gone back to check whether it still reproduces on 0.9.2.