golang/go · error

resolves to version %v (%s is not a tag)

Error message

resolves to version %v (%s is not a tag)

What it means

Thrown by codeRepo.Stat when the caller requested a canonical version string (one that equals its own CanonicalVersion), but resolving that revision against the VCS produced a different base version. The guard at coderepo.go:505-517 fires because a canonical request must resolve to itself (optionally with +incompatible); silently mapping it to a pseudo-version or other tag would be ambiguous. The (%s is not a tag) clause names statBase (the requested version with +incompatible stripped) to signal that the resolved tag does not literally exist in the repo under that name.

Source

Thrown at src/cmd/go/internal/modfetch/coderepo.go:514

					errIncompatible = invalidf("module path includes a major version suffix, so major version must match")
				} else {
					errIncompatible = invalidf("module contains a go.mod file, so module path must match major version (%q)", path.Join(r.pathPrefix, semver.Major(v)))
				}
			}
		} else if strings.HasSuffix(v, "+incompatible") {
			errIncompatible = invalidf("+incompatible suffix not allowed: major version %s is compatible", semver.Major(v))
		}

		if statVers != "" && statVers == module.CanonicalVersion(statVers) {
			// Since the caller-requested version is canonical, it would be very
			// confusing to resolve it to anything but itself, possibly with a
			// "+incompatible" suffix. Error out explicitly.
			if statBase := strings.TrimSuffix(statVers, "+incompatible"); statBase != base {
				return nil, &module.ModuleError{
					Path: r.modPath,
					Err: &module.InvalidVersionError{
						Version: statVers,
						Err:     fmt.Errorf("resolves to version %v (%s is not a tag)", v, statBase),
					},
				}
			}
		}

		if errIncompatible != nil {
			return nil, errIncompatible
		}

		return &RevInfo{
			Name:    info.Name,
			Short:   info.Short,
			Time:    info.Time,
			Version: v,
		}, nil
	}

	// Determine version.

View on GitHub (pinned to b6b368adc5)

Solutions

  1. Replace the requested canonical version with the correct pseudo-version (run `go list -m -versions <module>` to see available tags, or `go get <module>@<commit-hash>` to let the tooling derive the canonical pseudo-version).
  2. If you own the module, create the missing tag (e.g. `git tag v1.2.3 && git push --tags`) so the canonical version resolves to itself.
  3. For a replace directive pointing at a fork, ensure the fork publishes the same tags or pin to an explicit commit/pseudo-version.
  4. Clear the local module cache (`go clean -modcache`) and retry in case a stale proxy result is involved.

Example fix

// before
require example.com/m v1.2.3   // v1.2.3 was never tagged

// after (let tooling resolve)
go get example.com/m@e3702bed3d42e03e85e3a1e6b1a5a3d2
// resulting in a pseudo-version such as
require example.com/m v1.2.3-0.20240101120000-e3702bed3d42
Defensive patterns

Strategy: validation

Validate before calling

// Before pinning, confirm the requested version is a real tag.
// bash:
//   git ls-remote --tags <repo-url> | grep -F 'refs/tags/v1.2.3'
//
// In Go tooling, prefer letting the resolver derive the version:
//   go get example.com/m@<commit-sha>     // emits the correct version string
// Avoid hand-writing canonical versions that may not be tagged.

Prevention

When it happens

Trigger: Calling go get / module fetch with a version like v1.2.3 when the repo has no v1.2.3 tag but the revision is reachable (e.g. via a pseudo-version resolution path); statVers is canonical and statBase != base after incompatible handling. Also triggered by module proxies that canonicalize a request then fail to find the matching tag.

Common situations: A module consumer pins a version that was never tagged (only exists as a commit); tags were renamed or deleted upstream; using a fork via replace where the fork lacks the original's tags; proxy/goproxy cache returning a resolved revision that disagrees with the requested canonical version.

Related errors


AI-assisted analysis of golang/go@b6b368adc5 (2026-08-12). Data as JSON: /api/errors/1cea4beb80641ab0. Report an issue: GitHub.