Adrian Cole

zipkin server can upgrade its thrift independently as the important thing is that the serialization is compatible.

so the versions don't need to be interlocked as long as newer versions of libthrift don't change the serialization format. However, versions after 0.13.0 break classpath compatibility, which is an...

> Would bumping major be an option? yep sure

@zhfeng @anuraaga another option is to remove the thrift/scribe transport from camel. Zipkin has deprecated this for ages and the only main consumer is finagle, which doesn't use this code...

so add 👍 to just remove this transport on the next major release (stop publishing it)

after sleeping on it, I think in the special case of libthrift which I think the community is used to revlock forcing.. bump on next minor and cite in RATIONALE.md...

thanks for finding the setting @shakuzen. So, this is already configurable (and also tested as such in spring beans). someone who wants to set this to a higher value than...

this should be fine now, but re-open if there are any issues.

The dependencies here are to support existing applications, and often this conflicts with formal support life statements. As a few mentioned above, changing the okhttp3 code to depend on okhttp...

So, basically I agree [exactly what tommy said](https://github.com/openzipkin/zipkin-reporter-java/pull/205#issuecomment-1020807163).. it is likely this can be solved with dependency management (declare a version override or resolution in the build). This is because...