[Go] Add support for pseudo-version dependencies

[EtienneM]

Hi,

I hope the question has not been raised already but I couldn't find any relevant issues for the string "pseudo-version", "pseudo version" or "pseudoversion".

The Go language has the notion of pseudo-version. I saw a (old) blog article from Dependabot (https://dependabot.com/blog/go-modules-alpha/) stating that:

We don't update pseudo-versions, yet. In this initial release, we'll only upgrade semver-compatible versions. Support for upgrading pseudo-versions that point to a specific commit will follow shortly.

From what I experienced, Dependabot is not upgrading pseudo-version dependencies yet. Am I doing something wrong? Or is it still a work in progress?

Thanks a lot!

[danielwhite]

This has proved to be a bit of a pain point for an internal project. We don't really gain much value from tagging our internal repositories with semantic versions and typically want to follow the tip of the "main" branch.

Having Dependabot support these types of dependencies would be really useful.

#1025 explicitly prevented this. I'm curious if further thinking has been done by @hmarr about how it should work.

Are there any other package ecosystems that have a similar feature?

[hmarr]

It's been a long time since I worked on this, but I suspect my thinking at the time was: pseudo-versions point to a specific commit, and as a commit can exist in multiple branches, and be pointed to by multiple tags, it's not always clear what "update" actually means.

We encounter the same problem in other ecosystems and have a load of logic in the GitCommitChecker class to handle it, so it may just be a case of hooking the Go modules code up to that.

[aarongable]

I believe there are two interconnected issues here:

1. If a go module is currently pinned to a pseudoversion, dependabot is unwilling to suggest updates for it because it doesn't want to suggest an update to the wrong thing (e.g. a version on the wrong branch).
2. Also, dependabot is unable to suggest a pseudoversion as the next version to update to, because the go api it uses does not include pseudoversions: https://github.com/dependabot/gomodules-extracted/blob/231aee3c3b328099205403aa9ca857d1a12d6afb/cmd/go/_internal_/modfetch/repo.go#L32-L45

Unfortunately, this means that dependabot cannot update security-critical dependencies such as https://pkg.go.dev/golang.org/x/crypto, which never publishes semver-tagged versions.

I think in my mind the ideal algorithm here would be:

1. Detect if the dependency is a pseudoversion; assuming it is:
2. Detect if a version has been published with the same version number as the pseudoversion. If it has, update to that version; otherwise:
3. Detect if the pseudoversion's sha1 is reachable from the current HEAD of the repo's default branch (what you get checked out if you clone the repo). If it is, update to a new pseudoversion of the latest HEAD commit.

This means that, by default, pseudoversions are assumed to represent intermediate versions, and are updated to the next point release immediately after their current commit. But for modules that never release versions, pseudoversions get updated to the latest commit every time.

[DasSkelett]

Modules like golang.zx2c4.com/wireguard always resolve to pseudo-versions because the tags aren't in a semantic format (missing v prefix).
This means that unfortunately Dependabot never picks it up.
Ideally it would always update to the latest tag (which will resolve to a pseudo-version again), but having it update to the latest commit in the default branch would be a good start.

[elgohr]

@EtienneM the link to pseudo-versions moved to https://go.dev/ref/mod#pseudo-versions

[jakecoffman]

With #6713 pseudo-versions are now updated to tagged versions.

Let me know if you see any unexpected behavior with this change.

Dependabot will not update a pseudo-version to another pseudo-version. That is still an open question, but seems like it would be quite noisy.

[atc0005]

Dependabot will not update a pseudo-version to another pseudo-version. That is still an open question, but seems like it would be quite noisy.

Would be it feasible to offer an opt-in config setting for this type of update?

[jakecoffman]

I noticed updating to newer pseudo-versions was asked in 2020, so closing this one out as a duplicate: #2028

[elgohr]

@jakecoffman

Dependabot will not update a pseudo-version to another pseudo-version. That is still an open question, but seems like it would be quite noisy.

Any open issue on that? Would be great to have a reference here

[jakecoffman]

#2028 is tracking the feature request for updating dependencies to newer pseudo-versions