The main barrier towards supporting each Go version until EOL are dependencies. In particular, as seen in #2741, prometheus-operator packages can be quite aggressive when it comes to bumping their Go version requirements. As these dependencies account for our support for prometheus Custom Resources, not tracking upstream closely can get us into situations where we don't support some new attribute, but this lack of support isn't very discoverable for users.

In spite of what I claimed during our recent SIG meeting, the degradation is graceful, and within a given version, CRs are both forwards and backwards compatible with a given operator version. If the operator doesn't know about a particular attribute, it's simply ignored during deserialization. But we (obviously) still don't support it, and don't give any indication of this to users.

@jaronoff97 @pavolloffay how about we put the prometheus-operator version in the changelog alongside the instrumentation versions? Then we'd behave roughly the same way as prometheus-operator itself.

@swiatekm-sumo i would think we would put the compat matrix next to our matrix for kubernetes support, but yes I think that's a good idea. We'll also want to add some instructions for updating this in the release. I think I'm okay being a bit behind prometheus-operator given how eager they are, but I don't want us stuck many versions behind for more than a couple of months. I don't have strong feelings here though.

I like the alignment with the collector requirements for the go version. We could give it a try and see if it would impact our use of the promethues operator dependency.

We should also put prometheus operator into our compatibility matrix.