search

golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
123.18k stars 17.56k forks source link

x/crypto/x509roots/fallback: tag versions to reduce version churn from x/crypto commits #68637

Open rittneje opened 2 months ago

rittneje commented 2 months ago

Go version

n/a

Output of go env in your module/workspace:

n/a

What did you do?

If we do go get golang.org/x/crypto/x509roots/fallback@latest, since that submodule is not itself versioned, it instead uses the commit hash as the version.

The problem is that whenever we run this command in order to update our go.mod file, it is picking the version derived from the latest commit of x/crypto itself, instead of the latest commit that actually changed x/crypto/x509roots/fallback.

This is confirmed by https://pkg.go.dev/golang.org/x/crypto/x509roots/fallback?tab=versions

At present, that lists the latest version as v0.0.0-20240726163919-3375612bf41a, even though that commit had nothing to do with x/crypto/x509roots/fallback. https://github.com/golang/crypto/commit/3375612bf41a8cdb0cdfdc21e6ca2c7ae0f764b5

What did you see happen?

I expect the latest version of a submodule that is not tagged to be reported as the last commit that modified it (including deleting files).

Barring that, I expect x/crypto/x509roots/fallback to have tagged releases to avoid this problem.

What did you expect to see?

It changes constantly even though there really isn't a change, which is confusing and interferes with our ability to properly maintain our dependencies.

gabyhelp commented 2 months ago

Related Issues and Documentation

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

seankhliao commented 2 months ago

Given that go must be able to produce a module at a given commit, latest has to mean the latest version.

dmitshur commented 2 months ago

The x509roots/fallback module updates are done via a relui workflow. It currently only generates the CL (or possibly no CL if re-generating resulted in no diff). If there was a diff an a CL, it's a pretty good place for it to also create a tag, possibly after waiting for green post-submit.

CC @rolandshoemaker.

rittneje commented 2 months ago

Given that go must be able to produce a module at a given commit, latest has to mean the latest version.

@seankhliao I don't understand how the former implies the latter. If I have a tagged module, then latest will resolve to the latest tag, not the latest commit. However, that does not preclude you from manually specifying the latest commit instead.

For example, go get golang.org/x/crypto@latest (currently) resolves to v0.25.0, while go get golang.org/x/crypto@master (currently) resolves to https://github.com/golang/crypto/commit/3375612bf41a8cdb0cdfdc21e6ca2c7ae0f764b5.