We can wait for 1.2 to wrap up before merging this to prevent cherrypick conflicts.

GCE e2e build/test failed for commit 94b73bf0765c81c069bc2a8628f19a8db4225064.

• Build Log
• Test Artifacts
• Internal Jenkins Results

Please reference the list of currently known flakes when examining this failure. If you request a re-test, you must reference the issue describing the flake.

@nikhiljindal PR needs rebase

GCE e2e build/test failed for commit 23e90013ea980a5e9cb3d392938e85b56674740f.

• Build Log
• Test Artifacts
• Internal Jenkins Results

Please reference the list of currently known flakes when examining this failure. If you request a re-test, you must reference the issue describing the flake.

GCE e2e build/test failed for commit 7482f352f20b7251c032a4d9b2fa5b50c79444b1.

• Build Log
• Test Artifacts
• Internal Jenkins Results

Please reference the list of currently known flakes when examining this failure. If you request a re-test, you must reference the issue describing the flake.

@nikhiljindal PR needs rebase

LGTM @nikhiljindal, but needs a rebase. We can remove the do-not-merge label as soon as that's done, and v1.2 has been branched (i.e. in the next few hours).

Rebased. Removing the needs-rebase and do-not-merge tags.

PR changed after LGTM, removing LGTM.

Adding back LGTM since its just a rebase

GCE e2e build/test failed for commit f74de42e8d258597b95e547eecbde501350d5f09.

• Build Log
• Test Artifacts
• Internal Jenkins Results

Please reference the list of currently known flakes when examining this failure. If you request a re-test, you must reference the issue describing the flake.

GCE e2e build/test failed for commit 8683ff8f735c0513f8c060d7a52837f9c7e09b6b.

• Build Log
• Test Artifacts
• Internal Jenkins Results

Please reference the list of currently known flakes when examining this failure. If you request a re-test, you must reference the issue describing the flake.

#24054 is now submitted and cherrypicked in 1.2 so this PR is ready to go.

Rebased and the first commit is gone as #24129 updated go-restful.

This is now ready to go in and should go in soon since swagger spec is now broken on HEAD.
#24129 updated go-restful but did not update the spec (which should have been caught by the verify-swagger-spec script, if not for #24233).
Adding back the LGTM tag, since this was a trivial rebase.

Updated the title to reflect better release notes

cc @k8s-oncall since ./hack/verify-all.sh is currently broken on HEAD (but passes in our CI tests on jenkins and travis)

GCE e2e build/test passed for commit 6eae11e.

• Build Log
• Test Artifacts
• Internal Jenkins Results

@k8s-bot test this [submit-queue is verifying that this PR is safe to merge]

GCE e2e build/test passed for commit 6eae11e.

• Build Log
• Test Artifacts
• Internal Jenkins Results

Automatic merge from submit-queue

breaks kubectl 1.1

Our versioning policy states that we'll support back two minor versions, so v1.3 should support v1.1. Why did we decide this was okay?

I discussed this with @bgrant0607 and he pointed out that that policy doesnt talk about kubectl version skew.
Users are going to have a bad time if they try to use 1.1 kubectl with 1.3 apiserver since we have changed a lot of things.

I am not sure if any of our docs explicitly talk about kubectl and master version skew.
Also, am not sure if validation was on by default in kubectl 1.1.
Will find out and reply.

@ihmccreery Our version-skew policy is not clearly documented, and neither is the meaning of "support", but the "Supported Releases" section of that document is definitely not about version-skewed operation. See https://github.com/kubernetes/kubernetes/blob/master/docs/design/versioning.md#upgrades, for instance.

Practically speaking, kubectl even now isn't friendly to version-skewed operation. The most egregious problem is round-tripping #3955, which we plan to address in 1.3, but which means that any version of kubectl prior to 1.3 will still have that problem.

Seems to me the implicit assertion here is that we support kubectl only one minor version back. If so, we should document it as such. This is going to cause pain when we release v1.3 for anyone still running a v1.1 kubectl. Admittedly, no one "should" be, but...

cc @kubernetes/goog-gke @roberthbailey

I think the versioning policy was primarily created to account for the version skew between the master components and nodes. The best thing would be to make kubectl fail gracefully when it's incompatible with the apiserver and tell the user (kindly, without an arcane error or stack trace) that they should update. Supporting skew between the latest patch release of version 1.x and the new release of 1.y is important, because people will generally update one part of their system before the other (CLI tool / apiserver), but I don't think we need nearly as a wide a range as we intend for nodes. Also note that updating your CLI tool is quick and painless and doesn't have the side effect of possibly causing down time for your application. So encouraging updating it should be the default.

@nikhiljindal Does this PR require action by the user when upgrading to 1.3.0? (Think about non-developer users.) If so, please edit your first comment to have a release-note block, like in #28132. If not, please change to release-note-none.

@nikhiljindal if this is a breaking change, please update CHANGELOG.md.