Though I just realise that this will be our inclusion that makes us sensitive to breaking changes. People might be using older Admission Controller versions and we cannot break these queries / mutations ever (or at least until the version becomes unsupported). We need to document this somewhere as so far we have never needed to pay attention to this.
(...) I would start with some internal documentation in the cloud so everyone working on the code is aware of that? And having some automation/tests (either on Cloud or Admission Controller side) checking API compatibility could ensure that we don't break it accidentally.
For the future, there are some solutions like API versioning or providing consistency layer, but it requires some amount of work (and the question if we want to support it like this).
In general how we should handle breaking changes in Cloud API endpoints used by Admission Controller? Should we even allow for such or make sure backwards compatibility is always there?
As mentioned in this comment https://github.com/kubeshop/monokle-admission-controller/pull/12#issuecomment-1790309790:
In general how we should handle breaking changes in Cloud API endpoints used by Admission Controller? Should we even allow for such or make sure backwards compatibility is always there?