title: Kubernetes CRD versioning
body: <p>Kuberentes has a mechanism for supporting versioning of CRDs. See <a href="https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/" rel="noreferrer">https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/</a>. What is not clear to me is how you actually support an evolution of CRD v1 to CRD v2 when you cannot always convert from v1 &lt;-> v2. Suppose we introduce a new field in v2 that can not be populated by a web hook conversion, then perhaps all we can do is leave the field null? Furthermore when you request api version N you always get back an object as version N even if it was not written as version N so how can you controller know how to treat the object?</p>