client-go dependency recorded by go get is v0.0.0-...

[danderson]

I'm very happy about Go module support in v12! However, when I go get k8s.io/[email protected]. The dependency gets recorded in go.mod as:

k8s.io/client-go v0.0.0-20190620085101-78d2af792bab

I'm assuming this is because the client-go repository doesn't have the major version in the import path, so it reverts to legacy support behavior.

This is a maintenance headache, because it means that I can't easily go get -u my own package, because all the k8s packages will just sync up to master and (potentially) break everything.

Is there something the client-go repo can do here to make things behave more gracefully, so that downstream dependencies can track client-go by major version?

This is on Go 1.12 and client-go v12.0.0.

[liggitt]

I'm assuming this is because the client-go repository doesn't have the major version in the import path, so it reverts to legacy support behavior.

That's correct

Is there something the client-go repo can do here to make things behave more gracefully, so that downstream dependencies can track client-go by major version?

We're experimenting with adding major versions to import paths in kubernetes/publishing-bot#196, but it's not clear whether the impact (making all consumers modify all of their import paths) will be too disruptive yet.

[danderson]

Wonderful to hear!

While I know it's not a vote-based decision, I would greatly encourage moving in that direction. The upgrade between major versions of client-go is already a heavyweight operation, since it might contain breaking changes that require refactoring the consuming code. Running a a sed script to change import paths is a small additional tax on top of that other work (and the one-liner can be included in the release notes), but in return updating to keep up with e.g. security issues in all dependencies becomes a trivial go get -u ., rather than "surgically upgrade around client-go".

Thanks for the insight!

[liggitt]

closing in favor of kubernetes/kubernetes#72638 / kubernetes/publishing-bot#196