enh: go get of kubebuilder by tag doesn't work

[rbtcollins]

go get sigs.k8s.io/kubebuilder/cmd@v2.2.0
go get sigs.k8s.io/kubebuilder/cmd@v2.2.0: sigs.k8s.io/kubebuilder@v2.2.0: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

Alternative spellings fail in various related ways:

go get sigs.k8s.io/kubebuilder/cmd/v2.2.0
go: downloading sigs.k8s.io/kubebuilder v1.0.8
go get sigs.k8s.io/kubebuilder/cmd/v2.2.0: module sigs.k8s.io/kubebuilder@upgrade found (v1.0.8), but does not contain package sigs.k8s.io/kubebuilder/cmd/v2.2.0

I would expect kubebuilder to be go gettable, as that allows version-locking the kubebuilder version that is being used in go.mod/go.sum, with all the ensuing benefits that one would expect. Instead we have folk with curlsh scripts pulling down release builds versioned by hand...

Documentation on this is fairly comprehensive, but this bug comment is right at the heart of it: golang/go#33010 (comment)

tl;dr:

• Fix the import path- this repo is located on github, not on
• Put v2 in the module import path in go.mod
• Adjust code imports in this repo accordingly
• https://github.com/google/go-github is an example go library with a release major version greater than 1, that has code in master

Right now go get of the .../cmd path works fine, as long as one uses a hash, not a commit tag.

/kind bug

[DirectXMan12]

Yeah, so the issue was that kubebuilder wasn't intended to be a library originally -- it was just a tool. The rules for fetching go modules don't really admit the admit the existence of tools. For tools that aren't meant to be imported, bumping the major version without changing the import path is fine. That being said, since we now have folks trying to import parts, we should fix this.

Re "Fix the import path": nope, sigs.k8s.io is correct. Vanity imports are a thing in go. The vanity import resolves correctly.