-
Notifications
You must be signed in to change notification settings - Fork 411
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define a policy how the go version gets updated #2757
Comments
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. |
Component(s)
No response
Is your feature request related to a problem? Please describe.
Do we want to define a guideline like on the collector when to bump this version? Context => #2747 (review)
Describe the solution you'd like
Maybe similar to the opentelemetry-collector?
See: https://github.com/open-telemetry/opentelemetry-collector#compatibility
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: