Tested with:

cluster/kubectl.sh version
Client Version: version.Info{Major:"1", Minor:"2+", GitVersion:"v1.2.0-alpha.8.1354+144e818ae09b33", GitCommit:"144e818ae09b3339e2b54f3d8c1ae615024d6e51", GitTreeState:"clean"}
Server Version: version.Info{Major:"1", Minor:"1", GitVersion:"v1.1.8", GitCommit:"a8af33dc07ee08defa2d503f81e7deea32dd1d3b", GitTreeState:"clean"}

Most of the simple basic starting guides direct users to create a cluster with kubectl run. If I run kubectl 1.2 against a 1.1 cluster, I'll get the following behavior

cluster/kubectl.sh run nginx --image=nginx                   
Error from server: the server could not find the requested resource

now I happen to know I can get the old behavior by doing

cluster/kubectl.sh run nginx --image=nginx --generator=run/v1
replicationcontroller "nginx" created

but I don't expect an average user to know that or be able to find it easily. I'm mainly concerned that we will be breaking recommended flow for GKE users if they happen to use a new kubectl before their cluster's master is upgraded. We can just update our docs, but breaking a "porcelain" command seems like poor form. Other options include defaulting to the run/v1 generator for a few patch releases, and/or making kubectl run do some kind of version check so it can fallback to the run/v1 generator if deployments/jobs are not available.

@lavalamp @bgrant0607 thoughts?