Another option for release versioning proposal#2250
Conversation
Java will be fine, especially since we won't include the -alpha libraries in the BOM at all. You'll have to depend on them explicitly and intentionally in order to use them. |
|
I like this option also. It gives a nice experience / smooth transition for early adopters from alpha/beta -> RC -> GA. |
|
Although I'm working on C++ SDK, I like this option much better than appending |
| - SDK Stability: | ||
| - Public portions of the SDK (constructors, configuration, und-user interfaces) must remain backwards compatible. | ||
| - Precisely what this includes has yet to be delineated. | ||
| - Internal interfaces are allowed to break. |
There was a problem hiding this comment.
I guess this is referring to interfaces in the SDK that have the public modifier but don't fall into the above bucket. While I know Precisely what this includes has yet to be delineated. do you have any example of it? BatchSpanProcessor?
There was a problem hiding this comment.
I copied this out of Ted's otep...I think it just means non-public "internals" of the SDK. It might not be a valuable thing to call out.
There was a problem hiding this comment.
Ok - yeah it might be worth calling out but it applies to both API and SDK so weird for me to see it here, which I guess is my comment on the OTEP too so just repeating the feedback it seems :)
anuraaga
left a comment
anuraaga
left a comment
There was a problem hiding this comment.
Doc mostly LGTM, thanks
| - Once the API for a given signal (spans, logs, metrics, baggage) has been officially released, code instrumented with that API module will | ||
| function, *with no recompilation required*, with any API+SDK that has the same major version, and equal or greater minor or patch version. | ||
| - For example, libraries that are instrumented with `opentelemetry-api-trace:1.0.1` will function, at runtime with | ||
| SDK library `opentelemetry-sdk-trace:1.11.33` plus `opentelemetry-api-trace:1.11.33`. |
There was a problem hiding this comment.
But we planned to version SDK independently from API, right?
There was a problem hiding this comment.
I think this depended on how hard we go on preserving SDK compatibility. The more precise statement is indeed probably the use of the BOM for the latest version rather than mentioning them explicitly.
There was a problem hiding this comment.
I can update to refer to the BOM. Whether we actually end up versioning the SDK independently from the API remains to be seen (I sure hope we don't have to).
Co-authored-by: Nikita Salnikov-Tarnovski <gnikem@gmail.com>
Codecov Report
@@ Coverage Diff @@
## master #2250 +/- ##
=============================================
+ Coverage 0 87.42% +87.42%
- Complexity 0 2301 +2301
=============================================
Files 0 255 +255
Lines 0 8265 +8265
Branches 0 899 +899
=============================================
+ Hits 0 7226 +7226
- Misses 0 718 +718
- Partials 0 321 +321
Continue to review full report at Codecov.
|
jkwatson
requested review from
Oberon00,
arminru,
carlosalberto,
pavolloffay,
thisthat and
tylerbenson
as code owners
7 participants
As an alternative approach to #2212
This options adds
-alphato the released versions of immature libraries, rather than adding-experimentalto the artifacts.Another option to fulfill open-telemetry/opentelemetry-specification#1267