As noted in #36677, #36677 and rootlyhq/rootly-go#116, when Renovate encounters a Go module that's pinned to a commit hash (digest) which is ahead of the latest Git tag, we seem to always attempt to downgrade it to the last commit hash.
More investigation is required, but this is very likely to be due to the fact that we use semver for Go modules, which doesn't understand how Go module versioning works for "Pseudo Versions".
For example, using https://github.com/oapi-codegen/oapi-codegen as an example:
We can see that when https://github.com/JamieTanna-Mend-testing/gomod-downgrade is tested against, the digest pin is replaced by a release version update
(This is a slightly awkward example - v2.7.1 is a hotfix separate to the main branch's releases)
We'll roll this out in a few phases:
- add the new versioning scheme
- add it in some test repos + validate
- if it's looking good, enable it by default for the
golang datasource
As noted in #36677, #36677 and rootlyhq/rootly-go#116, when Renovate encounters a Go module that's pinned to a commit hash (digest) which is ahead of the latest Git tag, we seem to always attempt to downgrade it to the last commit hash.
More investigation is required, but this is very likely to be due to the fact that we use
semverfor Go modules, which doesn't understand how Go module versioning works for "Pseudo Versions".For example, using https://github.com/oapi-codegen/oapi-codegen as an example:
v2.6.1-0.20260501053733-08b30183ea8av2.7.0v2.7.0v2.7.1-0.20260618125644-2bf15250d004We can see that when https://github.com/JamieTanna-Mend-testing/gomod-downgrade is tested against, the digest pin is replaced by a release version update
(This is a slightly awkward example - v2.7.1 is a hotfix separate to the
mainbranch's releases)We'll roll this out in a few phases:
golangdatasource