What would you like to be added:

It would help the go modules ecosystem if k8s.io repos had tags that are semver format. From a user perspective it would also be nice if the tag matched the corresponding k8s version. This means today changing the approach of adding kubernetes-vx.x.x tags to vx.x.x on all k8s.io repos that come from staging/

Why is this needed:

The majority of the issues felt by the community when using go modules with k8s has to do with the fact that go.mod will resolve all tags to commits because valid tags are not found. This makes troubleshooting extremely hard. Each repo is only compatible with a specific version from another repo (ie client-go kubernetes-vx.x.x needs to match apimachiner kubernetes-vx.x.x). Sometimes things get messed up because of transitive dependencies and commits change and then compilations fails. It is very hard to determine which versions you have are incompatible because they are all random commits.

I've heard many times before that k8s doesn't follow semver and I assume that may be a reason that k8s.io repos aren't tagged as vx.x.x. Whether k8s follows semver or not I don't think really changes things. By applying a tag it will help clarify what the user is looking at but I do not think it will change the behavior of go modules in any way (except client-go, more on that below). So I see this as only helping.

One odd point will be client-go. client-go is the one package from staging/ that has it's own tagging scheme. client-go can continue forward with v12, v13, v14 if it wishes and also apply vx.x.x matching kubernetes. I believe this will work fine. For people that want to use the old versioning scheme of major numbers they can. go modules should prefer the v1.x.x tags because all the client-go tags greater than 1 (v2, v3, etc) are all incompatible modules (the import path is wrong. more info https://research.swtch.com/vgo-import). So even though applying two versioning schemes with tags is odd, I think it will work.