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

Potential collision and risk from indirect dependence 'hashicorp/go-immutable-radix' #310

Open
HappyHacker123 opened this issue Oct 6, 2024 · 0 comments

Comments

@HappyHacker123
Copy link

Description

hashicorp/memberlist has already opted into module and indirectly depends on hashicorp/go-immutable-radix through a GOPATH project. And project hashicorp/go-immutable-radix already opted into module and released a v2+ version with the major branch strategy. The latest module path of hashicorp/go-immutable-radix is "github.com/hashicorp/go-immutable-radix/v2" . From module-unaware project\'s perspective, it interprets the import path "github.com/hashicorp/go-immutable-radix" as hashicorp/go-immutable-radix\'s latest version. But from the Go Modules\' point of view, path "github.com/hashicorp/go-immutable-radix" equals to version v0/v1 or the latest version that doesn’t use the module. So when you try to get hashicorp/go-immutable-radix through the indirect path "github.com/hashicorp/go-immutable-radix" which comes from module-unaware project, the module pulls the old version of hashicorp/go-immutable-radix v1.0.0. While the latest version is github.com/hashicorp/go-immutable-radix/v2@v2.1.0 . This causes version of hashicorp/go-immutable-radix , which you are dependent on, sticked at the old version hashicorp/go-immutable-radix.

Solution

Add a replace directive in your go.mod files with version information to avoid sticking at the old version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant