Module Path Lacks /v4 Suffix Despite v4.x Releases, Causing Go Module Compatibility Issues

[uneet7]

The repository has released versions up to v4.x (e.g., v4.8.1), but the go.mod file still specifies the module path as:​

module github.com/kubernetes-csi/external-attacher

According to Go's module versioning guidelines, modules with major versions v2 and above should include the major version in the module path (e.g., github.com/kubernetes-csi/external-attacher/v4).​

This discrepancy leads to issues when using Go tooling. For instance, running:​

go get github.com/kubernetes-csi/external-attacher@v4.8.1

results in errors or unexpected behavior because the module path doesn't match the versioned import path expected by Go. PFA attached screenshot below

This affects developers who rely on tooling related to Go proxy to automate their go module upgrades, as it complicates the process of fetching and integrating the latest versions of external-attacher.​

Proposed Solution

To align with Go's module versioning requirements and ensure compatibility:​

1. Update the Module Path: Modify the go.mod file to reflect the major version, changing the module path to:​

   module github.com/kubernetes-csi/external-attacher/v4

2. Adjust Import Paths: Update all internal and external import paths within the repository to use the new module path with the /v4 suffix.​

3. Tag a New Release: After making these changes, tag a new release (e.g., v4.8.2) to provide a clear version point for users.​

Implementing these changes will help developers seamlessly integrate external-attacher into their projects using standard Go tooling.

[jsafrane]

The version tracks changes in the external-provisioner binary - a major
version bump means the binary now needs different cmdline arguments or new RBACs. No sidecar is really importable. We put no effort into making that clean or easy, and we don’t support it or make any guarantees of API stability, just like k8s.io/kubernetes.

Do you have a strong use case for importing the attacher?

[uneet7]

@jsafrane , To clarify, the use case here is not to import the module, but rather to query the available versions of the module in a clean and reliable manner.

For example, running the command:

GOPROXY=direct GOSUMDB=off go list -m -versions -json github.com/kubernetes-csi/external-attacher

returns the following output:

{
	"Path": "github.com/kubernetes-csi/external-attacher",
	"Versions": [
		"v0.2.0",
		"v0.3.0",
		"v0.4.0-rc.1",
		"v0.4.0",
		"v0.4.1",
		"v0.4.2",
		"v0.5.0-alpha.0",
		"v1.0.0-rc2",
		"v1.0.0",
		"v1.0.1-rc1",
		"v1.0.1",
		"v1.1.0",
		"v1.1.1",
		"v1.2.0",
		"v1.2.1"
	]
}

Notice that the latest available version is actually v4.8.2, but this command does not list it. This happens because the module does not follow Go module semantic import versioning conventions, specifically the major version suffix in the module path (e.g., /v4), which is required for versions v2 and above.

Now we have a usecase where we want to query the latest versions of side-cars and develop some tooling around it for automated cloud-provider binary upgrades, where fixing this issue would help.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten