#The new constraint `Error: incompatible
1 messages · Page 1 of 1 (latest)
A more general question along the same lines: Given the breaking compatibilities between sub 1.0 releases, does it make sense to always explicitly pin both the CLI and engine version? At least sub 1.0?
I thought engineVersion field in dagger.json was meant as informational only, and NOT as a hard minimum version constraint? cc @solid fossil @quaint arch
I may be missing something, but the situation you're describing Nipuna is specifically not supposed to happen. Just because you happened to run a module with 0.11.7 last time you pushed, doens't automatically mean it won't work on earlier versions.
It is, that field in dagger.json is completely unrelated to this.
There's version compatibility checks added in https://github.com/dagger/dagger/pull/7031, which is where the error is coming from
The error is correct in that there's an incompatibility between v0.11.6+v0.11.7 (OTEL related)
@buoyant widget because of that incompatibility, it actually wouldn't work even if the error didn't happen, it's just failing earlier and more descriptively. I think you may need to pin the CLI rather than always using the latest
curl -L https://dl.dagger.io/dagger/install.sh | DAGGER_VERSION=0.11.6 sh
Got it! Thanks for the extra context
That will install the CLI at v0.11.6. Not sure if that's how you were installing it Nipuna, let me know if that works or if we can help more
Thanks for looking at this! Yes i am pulling the CLI like that but installing the latest. I can pin it to an engine version. But the next time I run the pipeline it will fail again because now, the engine version is v0.11.7 and the CLI version is v0.11.6 right?
I'll still need 2 commits to update my engine image. First one with current CLI (0.11.6) and publish 0.11.7 engine, next one to update the CLI version to v0.11.7. Does that sound right? Neither version is forwards or backwards compatible right? They both have to match?