jaegertracing/jaeger-client-csharp

Rename projects to Jaeger.*

Closed this issue · 3 comments

cwe1ss commented

I'll move the discussion regarding the new project names into this new issue to not let the original issue (jaegertracing/jaeger#578 ) go off-topic.

From @cwe1ss:

Will the project still be called "LetsTrace" or will it be renamed to e.g. "Jaeger"? Seems a bit confusing to have a jaeger-client-csharp project that contains something called "LetsTrace" (which sounds completely tracer-independent).

From @Falco20019:

Personally, I would prefer to rename LetsTrace to Jaeger.Core and LetsTracer.Jaeger to Jaeger.Transport.Thrift. Then LetsTrace.Zipkin could be Jaeger.Transport.Zipkin. This would be in accordance to the already existing Jaeger.Thrift which is generated from jaeger-idl and would make it easier to see that Thrift transport consists of 3 projects and Zipkin is just the transport.

I also would like to see the following NuGET packages:

  • Jaeger.Core
    Only containing project Jaeger.Core
  • Jaeger.Thrift
    Containing projects Thrift, Jaeger.Thrift and Jaeger.Transport.Thrift
    Depending on NuGET Jaeger.Core
  • Jaeger.Zipkin
    Containing project Jaeger.Transport.Zipkin
    Depending on NuGET Jaeger.Core
  • Jaeger
    Depending on NuGET Jaeger.Thrift as an alias and easy way to keep up2date in case we change something

This would allow users to use Jaeger.Core + Jaeger.Zipkin if they only want to use the Zipkin transport without having to include Thrift at all, or just Jaeger + Jaeger.Zipkin. And the default user can just use Jaeger which allows as to remove Thrift runtime from NuGET Jaeger.Thrift and replace it by a dependency at a later point once there is an official release.

If you want to spare NuGET Jaeger.Thrift we can also just make that NuGET Jaeger (similar to who it's handled in Java).

/CC @yurishkuro @grounded042

From @cweiss:

I think that NuGet packages should have the same name as the underlying assembly.

Having a Jaeger.Zipkin package which contains a Jaeger.Transport.Zipkin.dll is confusing. The package should therefore be called Jaeger.Transport.Zipkin IMO.

(Having only "Jaeger.Zipkin" is confusing anyway as this just names two different products without telling how they are related to each other.)

From @Falco20019:

This would reflect how it's also done in the jave repository: jaeger-zipking and jaeger-thrift.

This naming scheme is also used by GRPC where GRPC is an alias for GRPC.Core. Jaeger.Thrift contains more than just one DLL compared to Jaeger.Zipkin. Those two would just be easier ways to include the wanted technology with all it's dependencies.

grounded042 commented

Here is what I'm thinking based on the above:

  • Jaeger.Core
    • what is currently LetsTrace
  • Jaeger.Thrift
    • the generated Thrift code
    • depends on wherever Thrift ends up, see #35
  • Jaeger.Transport.Thrift
    • what is currently LetsTrace.Jaeger
    • depends on Jaeger.Core and Jaeger.Thrift
  • Jaeger.Transport.Zipkin
    • what is currently LetsTrace.Zipkin
    • depends on Jaeger.Core
    • one thing of note here is that in my initial testing the LetsTrace.Zipkin did not work with Jaeger because of some JSON serialization issues.

I'm a big fan of only having one DLL per package and also matching DLL names with the package name.

  • 👍1
Falco20019 commented

I'm fine with @grounded042's proposal but would like to add one:

  • Jaeger
    • just an alias since most people don't read manuals or getting started guides
    • depends on Jaeger.Transport.Thrift
  • 👍1
grounded042 commented

This is complete as of #38