Skip to content

[Bug]: go.mod major-version mismatch breaks go get and forces insecure pseudo-versions #2691

Description

@gauravAggrahari

Describe the bug
The gpu-operator repository's go.mod declares the module as github.com/NVIDIA/gpu-operator (a v0/v1 path) even though release tags have moved to v23.x, v24.x, and beyond. Under Go's major-version suffix rule, any module at v2 or above must embed the major version in its module path (e.g. github.com/NVIDIA/gpu-operator/v24). Because this has not been done, downstream consumers cannot pin any released version with go get and are forced to reference arbitrary commits as pseudo-versions — a pattern that introduces real security and compliance risks.

To Reproduce

  1. Attempt to add the latest released version as a dependency:

    go get github.com/NVIDIA/gpu-operator@v24.x.y
  2. Observe the failure — Go cannot resolve the tag because the module path in go.mod does not carry the /v24 suffix required by semver.

  3. The only working workaround is pinning a raw commit hash, which produces an unresolvable pseudo-version such as:

    github.com/NVIDIA/gpu-operator v1.8.3-0.20260527175454-2369b0586cbd
    

    (base tag v1.8.3, timestamp 20260527175454, commit 2369b0586cbd)

Expected behavior

Downstream consumers should be able to run:

go get github.com/NVIDIA/gpu-operator/v24@v24.x.y

and have Go resolve the dependency to the correct, signed release tag.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementImprovements to existing features, performance, or usability (not bug fixes or new features).

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions