This issue is a proposal and collection of work-items for the cluster versioning mechanics for 1.0. It is meant to contain concepts from #2524 and decisions from the 2015/02 Kubernetes Meet-up as to what to encapsulate/cut for 1.0:

Versioning requirements for kubelet:

• kubelet version tuple must be reported for the cross-product of, at least, (kubelet, docker, kernel).
  apiserver. Since, as we'll see in the Upgrade section, these versions are bundled, the tuple itself may be encodable linearly (i.e. "kubelet image 97" for a given cloud provider / node image.) (Kubelet publish node components' version #5948)
• It should be easy to query the current versions of all kubelets from the API.
• apiserver must speak only the capabilities of the least capable kubelet software version (the first part of the tuple)
• apiserver of version n.x must be accessible to a kubelet of version n.y if x>=y. When in doubt, the versioning policy trumps this issue as to what API versions are required to interoperate, except that for 1.0 master components are always allowed to assume they're ahead of kubelet.