Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

cmd/go: module commands fail to resolve version tags that include metadata #26605

Closed
marwan-at-work opened this issue Jul 25, 2018 · 2 comments
Closed

cmd/go: module commands fail to resolve version tags that include metadata #26605

marwan-at-work opened this issue Jul 25, 2018 · 2 comments
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Go1.11

Comments

@marwan-at-work
Copy link
Contributor

marwan-at-work commented Jul 25, 2018 •
edited

Semver metadata are considered valid by the semver spec, however Go modules do not work when you try to go get a tag that has metadata.

Although cmd/go/internal/semver.IsValid returns true when the input is v1.2.3-alpha+mymeta the cli does not work across get, build, and list commands. This is because Go strips all build metadata before issuing fetch commands. For example, if the tag in a git repo is v1.2.3+meta, Go will ask that git repo to give it v1.2.3 which does not exist.

Go version: tip
Go env: all.
@bcmills bcmills added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. modules labels Jul 25, 2018
@bcmills
Copy link
Contributor

bcmills commented Jul 25, 2018

According to semver.org, “Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence.”

If we were to allow v1.2.3+meta as a durable version tag, then the repo maintainer comes along and tags some other commit with v1.2.3+other, how would we resolve that? They're supposed to be semantically equal, but we would either have to prefer one over the other (violating the SemVer spec) or error out (an unpleasant possibility, since the Go user doesn't have control over what extra tags the repo maintainer may add).

That seems to imply that we should resolve the v1.2.3-alpha+mymeta tag to a pseudo-version (probably v1.2.3-alpha.0.YYYYMMDD-etc) and then issue commands using the commit hash from the pseudo-version instead of the tag.

@bcmills bcmills added this to the Go1.11 milestone Jul 25, 2018
@bcmills bcmills changed the title cmd/go: go modules does not allow metadata cmd/go: module commands fail to resolve version tags that include metadata Jul 25, 2018
@rsc
Copy link
Contributor

rsc commented Jul 26, 2018

This is working as intended. There needs to be a single canonical tag we look for, and that tag is the tag with metadata stripped. Semver says that v1.2.3-alpha and v1.2.3-alpha+metadata should mean the same thing, so we look for v1.2.3-alpha.

Note that our mapping of git tags to go versions is not anticipated by nor controlled by the semver spec, of course.

@rsc rsc closed this as completed Jul 26, 2018
@golang golang locked and limited conversation to collaborators Jul 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge modules NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Go1.11
Development

No branches or pull requests
4 participants
@rsc @bcmills @gopherbot @marwan-at-work