4.6.0

Type	Description	Link
Improvement	Tracing uniquely identifies requests with request metadata and a _requestId MDC property.	#574

4.5.2

Type	Description	Link
Fix	Upgrade dropwizard version to 2.0 to get rid of outstanding javax references	#565

4.5.1

Type	Description	Link
Fix	Switch javax dependencies to equivalent jakarta dependencies	#564

4.5.0

Type	Description	Link
Improvement	RandomSampler provides a static factory, preferred over the constructor to advantage of deterministic values (zero and one).	#561

4.4.0

Type	Description	Link
Feature	Publish tracing-test-utils	#442

4.3.0

Type	Description	Link
Feature	Provide Tracing support for the full Undertow request lifecycle	#400

4.2.1

Type	Description	Link
Fix	Prevent NoSuchMethodError on Tracer.getTraceMetadata caused by ABI break when using tracing-okhttp <=4.1.0 and tracing 4.2.0.	#395

4.2.0

Type	Description	Link
Improvement	Make Tracer#getTraceMetadata public to allow third party libraries to propagate trace related ids	#387

4.1.0

Type	Description	Link
Improvement	Add a new endpoint to support wrapping Callables with alternative trace ID.	#375

4.0.0

Type	Description	Link
Break	Scheduled executor recurring tasks are always given new trace IDs Previously we had no good options for scheduled executors: Either create a new traceId for every taskd regardless of whether it was submitted to execute(runnable) or scheduleWithFixedDelay which mean very different things. Recurring tasks are most frequently scheduled on application startup and continue to execute at a cadence until the service is halted. In these cases we used to produce large traces bounded by the runtime of the application, making the traceId of an error thrown in this context unhelpful for debugging. In worse cases, lazily scheduled tasks are created with the traceId of a request that happened to cause lazy initialization, resulting in tracing state that incorrectly blames to a particular user request. While there are cases that we may want to preserve a single traceId across a scheduled task, they are sparse and complex. In these cases it's reasonable to expect developers to wrap tasks before scheduling them with an executor to acknowledge the desired behavior, and make it clear to others who read the code.	#362