We have a couple of action items here. An initial suggestion could be:

1. Establish a version policy for Kafka support. For instance, in the Kubernetes world, it's common to support N-2 minor versions. Our promise on the operator is then that people can use any one of those 3 versions and expect Jaeger to work.
2. Once the policy is established, document it.
3. We can then use the latest version in the CI tests, with the other versions as part of a nightly build. This way, we keep the CI waiting times short, while still catching issues in a timely fashion. This can be a job that can be triggered on-demand as well so that we run it before releasing as well.

About the nightly jobs: I think we could even consider moving some of the tests we have from the CI to the nightly build as well.

Rinse and repeat for other storage mechanisms :-)

Great topic :)

Note that in the future Jaeger will use Kafka implementation from OTEL collector. It's a newer implementation that does not use deprecated sarama-cluster implementation. Therefore the OTELcollector might be a better place for the itest.

Special thanks @Ashmita152.

Excellent topic

Hey @yurishkuro , is this issue open to work on, I would love to complete it.

hi @Mayank77maruti - sure, give it a try. We have examples of testing different backend versions with Elasticsearch.

Hi @Mayank77maruti, are you still working on this? If you don't have much time, I would like to give it a try.

Hey @zzzk1 i am not working on it.
@zzzk1 you can take up the issue.
Thank you.