#`dagger update` does not update dagger dependencies

1 messages · Page 1 of 1 (latest)

brazen vault
#

I've noticed that dagger update does not seem to update a dagger module's dependencies.

Suppose I have a module which contains one dependency: github.com/shykes/daggerverse/hello@hello/v0.2.0.

Then, as a user, I notice with excitement that version v0.3.0 has dropped, so I try to update it with dagger update hello.
I would then expect that the dagger.json manifest would be updated to point to v0.3.0, but it remains at v0.2.0.

Is this intentional and have I just misunderstood how update is supposed to work?

For reference, I'm on dagger v0.20.6.

brazen vault
#

Bumping this.

finite vale
finite vale
#

@brazen vault I just double checked and dagger update doesn't do semver updating. It will update the pin of the module if the @$version is a moving target

echo creek
#

There's been a whole design debate about that last year - I personally find the current behavior annoying

#

(Because I also expect dagger update to actually update)

warm nexus
#

Is there a known dagger version where this had a different behavior ?

echo creek
#

Not to my knowledge no

brazen vault
#

Thanks for the replies.

I think maybe that the documentation for update would have to be clarified so it is more clearly understood what entails with updating a dependency.

In this case, I like the approach from Cargo in the Rust ecosystem: If a dependency is locked at some major version, it would allow for continuous upgrades of minor/patch versions, while keeping the major version fixed.

In my example here with going from hello@v0.2.0, if there was a new v0.3.0 release I would expect the dagger module manifest to be pointing to this release after running update.

@finite vale : I agree with you that if @$version is specified as a moving target, be it a branch, it would make sense that the manifest would update the pin. But I think in the case for tags, which normally don't change. With the combination of a version naming convention, it should be possible to have some mechanism in update where if the $version is specified as a tag following semver, the subcommand would constitute a version bump.

I'm not sure if that the dagger ecosystem has any strong enforcement on the tag names being semver, though.

finite vale
#

In this case, I like the approach from Cargo in the Rust ecosystem: If a dependency is locked at some major version, it would allow for continuous upgrades of minor/patch versions, while keeping the major version fixed.

In my example here with going from hello@v0.2.0, if there was a new v0.3.0 release I would expect the dagger module manifest to be pointing to this release after running update.

how would you specify in this case if you want to lock the major or the minor? NPM uses special characters like ^ , ~ x for that.

#

I'm not sure if that the dagger ecosystem has any strong enforcement on the tag names being semver, though.

it's suggested but there's no strong enforcement, no

brazen vault
echo creek
finite vale
#

it has been widely adopted by the web ecosystem. Seems like Cargo has decided to follow apparently

#

but it's not a proper "standard"

echo creek
#

I think in Python there is another syntax no?

finite vale
#

yes, it's part of the python spec:

brazen vault
#

I don't have much experience with working with JS / NPM, but in Rust using semantic versioning is standardized. There exists libraries that can parse the versioning scheme since this scheme already is well spec'ed, see here: https://semver.org/

#

Not trying to push any mandate, but I think if dagger would have a standardized way of versioning, I think it would make the behavior of commands like update more expected.

echo creek
#

@brazen vault semver is a given, but it doesn't standardize a syntax for version constraints. That's the part that is fragmented across language ecosystems and therefore more tricky to standardize in a cross-language platform like Dagger