From d8a4e4dd831f2779c22534b4546f0baa866148cd Mon Sep 17 00:00:00 2001 From: Yuri Shkuro Date: Tue, 16 Jul 2024 12:45:15 -0300 Subject: [PATCH] Require separation of API and SDK artifacts (#4125) --- specification/library-guidelines.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specification/library-guidelines.md b/specification/library-guidelines.md index a18e5429b78..043885078b0 100644 --- a/specification/library-guidelines.md +++ b/specification/library-guidelines.md @@ -14,7 +14,7 @@ _Note to OpenTelemetry client Authors:_ OpenTelemetry specification, API and SDK 1. The OpenTelemetry API must be well-defined and clearly decoupled from the implementation. This allows end users to consume API only without also consuming the implementation (see points 2 and 3 for why it is important). -2. Third party libraries and frameworks that add instrumentation to their code will have a dependency only on the API of OpenTelemetry client. The developers of third party libraries and frameworks do not care (and cannot know) what specific implementation of OpenTelemetry is used in the final application. +2. Third party libraries and frameworks that add instrumentation to their code will have a dependency only on the API of OpenTelemetry client. The developers of third party libraries and frameworks do not care (and cannot know) what specific implementation of OpenTelemetry is used in the final application. To enable this clean separation, the OpenTelemetry API and SDK libraries MUST be provided as independent artifacts. 3. The developers of the final application normally decide how to configure OpenTelemetry SDK and what extensions to use. They should be also free to choose to not use any OpenTelemetry implementation at all, even though the application and/or its libraries are already instrumented. The rationale is that third-party libraries and frameworks which are instrumented with OpenTelemetry must still be fully usable in the applications which do not want to use OpenTelemetry (so this removes the need for framework developers to have "instrumented" and "non-instrumented" versions of their framework).