GA timeline

[joaoandremartins]

When is this project planned to go GA?

Spring Cloud GCP wants to go GA but can't depend on any non-GA dependencies. We rely on zipkin-gcp to send Sleuth traces to Stackdriver Trace, but the version is still 0.4.1.

[codefromthecrypt]

The version number status applies as there hasn't been enough feedback to suggest it is stable yet. Time won't change that, feedback will. The code in spring cloud gcp itself was similarly very new and without a lot of feedback. I'm surprised spring cloud gcp itself is 1.0 (aka GA) on this functionality, as I've similarly seen little feedback on it outside of maintainers. Maybe I missed it?

Spring-cloud-sleuth itself has <1.0 optional library dependencies (for example opentracing has been unstable and still <1.0). I'm not sure how spring-cloud-gcp has a higher barrier than sleuth on this regard.

At any rate, lets break down where the concern might arise from so you can get sensible advice.

• The only consumer of zipkin-reporter is zipkin code, not user code. There's no api liability for users
• The only entrypoint of api exposure is the sender's builder which is unlikely to change unless you request it
  • Since there has been little feedback and the primary source of feedback would be spring-cloud-gcp we shouldn't lock this into a version 1.0 as it would prevent us from changing the builder if you need an adjustment.

So, my suggestion is to review the code in question and then ask if you need a higher standard for an optional dependency than sleuth has. If instead you are looking for a mandatory dependency, you relatively simply use maven's shade plugin to repackage the code here (ex shade zipkin2.reporter.stackdriver as X.X.internal) until such time as it is ready. Once it is, we flip the version here and you remove the shade. Remember the size of the bytecode here is very small so repackaging it is not going to add much weight to spring-cloud-gcp should you go that way.

For us to be 1.0 here, we need more feedback. In zipkin, we've never rushed a version to 1.0 based on an arbitrary timeline, and definitely won't here. It is best for the users to be honest.

[codefromthecrypt]

to answer the 1.0 question more directly, here's a gate:

We use rule of 3 on most things, so at least 3 production sites using this code (or at least saying they would) is a minimal barrier. Moreover, as this is designed for use in tools like spring-cloud-gcp, we'd want to have a nod from there.

Meanwhile, folks can use this (build experience etc) by using the example below or in other tools (like dropwizard etc) until it is usable via spring-cloud-gcp https://github.com/openzipkin/sleuth-webmvc-example/tree/use-stackdriver-sender

A side note: we are building zipkin collector v2 in the next few weeks. It would be most convenient to release version 1.0 without the old collector code as it causes least confusion. So, I would prefer to not release this prior to finishing https://github.com/openzipkin/zipkin/issues/2047

[codefromthecrypt]

fyi I will implement https://github.com/openzipkin/zipkin-gcp/issues/67 (removing to span ID mapping) as it is mostly tech debt for reasons mentioned. This has to happen prior to 1.0 as it is behavior changing.

[joaoandremartins]

Thanks for your response!

What sort of feedback would you expect users to file with us? We're just an integrating layer in the middle, the integration seems to be working without any issues. We are seeing a considerable volume of calls to our Trace integration, so I'm assuming if users aren't seeing issues. We've also reached a point where, to get more usage, we need to go GA.

We will also need to wait for Sleuth to go GA, so no worries there.

It's perfectly fine if you need more time to finish any pending issues. I just thought we could initiate this conversation sooner rather than later and, e.g., possibly come up with a list of GA blockers on this side.

[codefromthecrypt]

@anuraaga @joaoandremartins so I'm releasing v0.5.0 now which has the same versions of things as sleuth (which I didn't realize went RC2 5 days ago)

Sleuth won't be final until after everything else in finchley is final, currently 13 June https://github.com/spring-cloud/spring-cloud-release/milestones

So, please do test what's out there, but hopefully we can keep it real... for example we are not holding back things which go GA when sleuth does until after sleuth goes GA

[meltsufin]

@adriancole Any updates on this? When do you expect to release 1.0.0? Thanks!

[codefromthecrypt]

@joaoandremartins how are things on your end? should we be 1.0.0?

[meltsufin]

@adriancole We don't have any issues on our end, but we can wait a week or two before 1.0.0. We've just release RC1 of spring-cloud-gcp yesterday. Also, are there plans to make the dependency part of the Sleuth BOM? BTW, Joao has moved on to other projects.

[codefromthecrypt]

@adriancole We don't have any issues on our end, but we can wait a week or two before 1.0.0. We've just release RC1 of spring-cloud-gcp yesterday.

Makes sense to me

Also, are there plans to make the dependency part of the Sleuth BOM?

sleuth doesn't have a bom :) but I know what you mean. Typically we don't add things to sleuth just to track versions.. usually there's a conditional autoconfiguration. Mind opening or adding to an issue there with what you have in mind?

[meltsufin]

What I meant by "Sleuth BOM" is the spring-cloud-sleuth-dependencies artifact. We're already importing it in our POM. If it doesn't make sense to keep it there, we can just continue to specify the zipkin-gcp version directly in our POM.

[codefromthecrypt]

fyi 0.6.3 out with version bumps notably zipkin 2.10 which only uses the v2 read endpoint (not really relevant here because the server is a write proxy only)

[codefromthecrypt]

fyi 0.9.0 is out cc @mtwo this sorts out some of the recent propagation issues

[codefromthecrypt]

sorry about this, we've been >1.0 for a bit now