Release 1.x

[yurishkuro]

@Falco20019 any reason not to go to 1.0 version? I think this lib is production ready.

[Falco20019]

I would first want to finish #116 and #57 since those are huge breaking changes. Especially since we already know that we want to invert the Thrift dependency before we have GRPC as alternative. This will change the naming of the NuGET packages.

The most significant ones are already part of the 0.4.0 milestone. So maybe we rename it to 1.0.0.

[yurishkuro]

sounds good.

[rstraszewski]

Hi, any ETA for version 1.0?

[Falco20019]

One of the main blockers was Apache Thrift. https://issues.apache.org/jira/plugins/servlet/mobile#issue/THRIFT-2947 Was fixed just yesterday.

I assume we can target the 0.4.0 milestone the next 3-4 weeks and might then release v1.0.0

[brunosantosfarfetch]

Hi,

Does the Release 1.0 have any plans to be released yet? It would be great to have the official CSharp jaeger lib production-ready.

Regarding the comment above and having into account that THRIFT is deprecated it shouldn´t block the release, or I'm missing something?

Willing to help you guys in anything that is needed to move this. I'm currently using Jaeger in production but since our stack is mainly C# we are using Zipkin client. It would be great to have this one to use all the jaeger features especially regarding sampling strategies (remote configuration)

Thanks.

[Falco20019]

Hi @brunosantosfarfetch, sorry for the late response.

AFAIK https://github.com/jaegertracing/jaeger/issues/773 is still open. That's why we haven't moved on with #139. So Thrift is currently still the default and #116 and #57 are still the blockers.

I will have a look the next weeks since 0.13.0 of THRIFT might have the support that was blocking. Currently I'm sadly pretty full with all the crazyiness.

[Falco20019]

I try to focus on 0.4.0 this week, so we should get a lot closer to 1.0. 0.4.0 already prepares for getting rid of THRIFT in the long-run and introduces the necessary breaking changes.

[Lercher]

It's more a question: won't there be (nuget) support for Framework 4.x in version 1? Trying that for 0.3.7 yields:

Install-Package : Could not install package 'Jaeger 0.3.7'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.5', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

[Falco20019]

We are currently targeting netstandard2.0 and therefore .NET Framework 4.6.1+ and .NET Core 2.0+. I will have a look, if we can add the net45 moniker to the TargetFrameworks or if any dependency is blocking this.

[Falco20019]

@Lercher I just gave it some love and it sadly won't be possible to support .NET Framework 4.5. We have a dependency on Microsoft.Extensions.Logging.Abstractions 2.0.0 due to the NullLoggerFactory being added there first. For Microsoft.Extensions.Configuration.EnvironmentVariables we could go down all the way to 1.1.2 which supports net451.

We also use ApacheThrift which only support netstandard2.0 and therefore also just net461 as minimum. But the plan is to get rid of this dependency and have gRPC as alternative which would have net45 support. Bringing Microsoft.Extensions.Logging.Abstractions usage down to a version that supports net451 would need us to add a fallback for some of the logging framework.

So I think your best bet right now would be to target .NET Framework 4.6.1 if you don't have the requirement to stay on net45. You would still be able to support all OS versions up to and including Windows 7 SP1. Windows Vista SP2 is the first unsupported OS. Windows 10 November Update (version 1511) was the first to include net461 pre-installed. So you might need to install the runtime if you have to support older systems.

Let me know if this clarifies your problem or if we should look into supporting net45. Microsoft ended the support on January 12, 2016 for these versions, so if you are using HTTPS you might want to target newer versions anyway to have latest TLS support. (see https://devblogs.microsoft.com/dotnet/support-ending-for-the-net-framework-4-4-5-and-4-5-1/)

[Lercher]

@Falco20019 That's really cool, I'm fine with 4.6.1 personally. Due to expectable heavy workloads migrating to 5.x, however, I guess there is common appreciation for support for any 4.x.

But the plan is to get rid of this dependency [Thrift] ...

As I understand it, Jaeger's agent doesn't support gRPC ingress, only Thrift (right?) So does that mean that the agent won't be supported any more? (My source on agent's connectivity: https://www.jaegertracing.io/docs/1.18/security/ and https://www.jaegertracing.io/docs/1.18/deployment/#agent )

[yurishkuro]

The new agent based on OpenTelemetry collector does support gRPC ingress.

[Falco20019]

@Falco20019 That's really cool, I'm fine with 4.6.1 personally. Due to expectable heavy workloads migrating to 5.x, however, I guess there is common appreciation for support for any 4.x.

Newer versions like 4.7 and 4.8 have better support for .NET Standard with less clutter in dummy DLLs produced. So the later you can get, the better. Supporting 4.x older than 4.6.1 is currently pretty hard when developing against netstandard as you have to hop a lot of extra loops.

But the plan is to get rid of this dependency [Thrift] ...

I only meant the hard dependency as part of Jaeger.Core. Starting with 0.4.0, the plan is to be able to choose what sender you like instead of always having to include Thrift. See #139. Right now, even if you do not intent to talk to the agent, you would still need to include Thrift which is annoying.

[Lercher]

Sorry if there’s a misconception, I’m not native English speaking: please read my „any 4.x“ not as „all 4.x“. So „4.6.1 or later“ is greatly welcome.

[Falco20019]

I look into finally releasing 1.0.0 since there haven't been any big issues lately and the crucial changes were also through.

[Falco20019]

We just release our first major version. Thanks to everyone for the support!