Planning for deprecation and backward compatibility

In the previous section, we discussed the work needed to release a new version of an Operator. While the processes for bundling and publishing a new version are relatively simple in terms of the effort required, implementing a new API version is not an insignificant task. As such, doing so should be done only as necessary in order to minimize the use of engineering resources and disruption to users.

Of course, it will occasionally be unavoidable that incompatible changes must be introduced, for example, in the case of deprecation. Some of this deprecation might even come from upstream, where it is beyond your direct control (see the Complying with Kubernetes standards for changes section). However, the frequency of such changes can often be controlled through careful planning. In this section, we'll discuss some ways to plan for deprecation and support backward compatibility without causing undue strain on your engineers...