Allow backward compatible changes in CRD

[nicolaferraro]

Let's consider the following scenario.

I have a knative controller that reads and write camel K integrations. It imports the camel k apis, version 0.3.3.
After some point in time we release 0.4.0 with an additional field "version".

Technically the knative controller can ignore that field, but in practice it can't, because the kubernetes unmarshalling fails when mapping the integration json into the 0.3.3 structs (that miss the "version" field).

Everything would be easier if we ignore unknown properties by default, by sending them into a "unknownFields" map struct during unmarshalling.

This would make the handshake between a super controller and camel k integrations easier, because the super-controller can depend on camel k version 0.4.x+ and not a precise version.

Versioning the resources does not help.

[valdar]

From a different angle, doesn't this mean that changes in camle-k model/apis should be regarded as a breaking change not suitable for a minor release?

[nicolaferraro]

Currently yes. If we consider that package is "public", meaning that other projects can build on top of that (and I currently count at least two opensource projects building on top of that: Knative and Syndesis), they should not be broken at every release.
I don't think we'll solve anything doing major vs. minor reasoning, because people often want to use latest Knative with latest Camel K and expect that to work. API is now v1alpha1, but we should solve that problem before v1.