#The new constraint `Error: incompatible

1 messages · Page 1 of 1 (latest)

tulip charm
#

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?

torpid rampart
#

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.

quaint arch
#

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

torpid rampart
#

Got it! Thanks for the extra context

quaint arch
buoyant widget
#

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?