This PR is not for the master branch but does not have the cherrypick-approved label. Adding the do-not-merge label.

This change is 

/lgtm

why wouldn't we tightly bound the versions the workaround applies to? (>= 1.4.0, <1.5.0)

Thanks, i updated the code as suggested. Also updated the PR description. PTAL.

Are we also fixing the v0.0.0 issue in head?

i think it has always been like this. Only when we make a release will the version be written to base.go, so it's not a bug.

Are we also fixing the v0.0.0 issue in head?

i think it has always been like this. Only when we make a release will the version be written to base.go, so it's not a bug.

I don't think it has always been like that. Building from a branch off of master just before the release-1.5 branch was cut (a3ba760) with a random commit of my own added on top, I get

User-Agent: kubectl/v1.5.0 (darwin/amd64) kubernetes/a3ba760

the issue might be that the build scripts only set vars under k8s.io/kubernetes/pkg/version, and once we switched to the client-go base.go, it stopped getting dynamic vars

kube::version::ldflag() {
  local key=${1}
  local val=${2}

  echo "-X ${KUBE_GO_PACKAGE}/pkg/version.${key}=${val}"
}

Thanks @liggitt. Tried the following and the rewrite still doesn't work:

echo "-X ${KUBE_GO_PACKAGE}/pkg/version.${key}=${val} -X k8s.io/client-go/pkg/version.${key}=${val} -X vendor/k8s.io/client-go/pkg/version.${key}=${val} -X staging/src/k8s.io/client-go/pkg/version.${key}=${val}"

Thanks @liggitt. Tried the following and the rewrite still doesn't work:

echo "-X ${KUBE_GO_PACKAGE}/pkg/version.${key}=${val} -X k8s.io/client-go/pkg/version.${key}=${val} -X vendor/k8s.io/client-go/pkg/version.${key}=${val} -X staging/src/k8s.io/client-go/pkg/version.${key}=${val}"

The go path is k8s.io/kubernetes/vendor/k8s.io/client-go/...

building from HEAD with this:

  echo "-X ${KUBE_GO_PACKAGE}/pkg/version.${key}=${val}"
  echo "-X ${KUBE_GO_PACKAGE}/vendor/k8s.io/client-go/pkg/version.${key}=${val}"

produces

User-Agent: kubectl/v1.7.0 (darwin/amd64) kubernetes/4c4c9e4

opened #42623 with the build fix

if we get #42623 merged, I don't feel strongly about patching this version check

@liggitt may i get the lgtm? Thanks.

in the abstract, the bounded version check LGTM, given the v0.0.0 issue is a bug we can fix, I'm unsure whether it's worth updating the 1.5 release for that

Hmm, let's still merge this. It's a pure improvement. We might break kubectl again, this pull will save people from debugging the issue again.

did the previous unbounded check allow kubectl 1.3 to work against 1.5?

1.5 apiserver will hide the apps and the policy groups from 1.3 kubectl, so 1.3 kubectl apiversions won't see those two groups. Other than this, 1.3 kubectl works.

so tightening it breaks kubectl 1.3, which is outside our 1 version skew support statement, but makes this not a pure improvement. I could go either way.

Excuse my English, I used the wrong tense. I mean without the tightening, "1.5 apiserver is hiding the apps and the policy groups from 1.3 kubectl, so 1.3 kubectl apiversions doesn't see those two groups." With the tightening, 1.3 kubectl can see these two groups enabled, though it still cannot do any CRUD operations because the lack of the scheme. So this pull is a pure improvement.

ok, so 1.4 was the only version that had the "already registered" problem?

Sorry,1.3 is affected by the "already registered" change, 1.2 is not. We should tighten the version to >=1.3 and <1.5.

[update] I've updated the code.

(the line caused the bug is merged on Mar. 31, 2016: #18835)

/lgtm

[APPROVALNOTIFIER] This PR is NOT APPROVED

The following people have approved this PR: caesarxuchao, foxish, liggitt

Needs approval from an approver in each of these OWNERS Files:

• pkg/OWNERS

We suggest the following people:
cc @smarterclayton
You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

@mwielgus I think you are managing the 1.5 branch, could you approve this pr to the 1.5 branch?