-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add API to query OpenTracing version at runtime #33
Comments
Assuming we do this, it is small and should go in earlier rather than later... Assigning milestone accordingly. |
I am not quite clear on how we expect users to use it. In any case, to future proof it we can return some "metadata" / TracerInfo object that for now would only expose the |
I would advocate for some mechanism of exposing the version. As for the particular mechanism of delivering that version info (method vs object), I don't feel strongly as long as it's the same for 1.0 and 1.0+ or else the point is somewhat missed :) My opinion is mostly driven by my experience working with public APIs, where I've found exposing version to be a best practice as forward/backward compatibility issues -- as much as they're not desired -- do inevitably arise in the imperfect world of practice. As for a use case, I'm making this up off the top of my head, so I forgive me if this is not the best example:
The crux of my argument is it's lot cleaner for me (the implementor of that jQuery library) to add a fail-fast check against It also affords me an opportunity to polyfill a All of this is of course not an issue in any configuration where all the binding can be done purely statically and not at run time. Note it's also a little hard to make a rock solid case for this since it's very much about future-proofing, not addressing an existing limitation or problem; such is the joy of forward-compatibility concerns :) Hope that makes sense! |
@bcronin thanks for the background, quite useful. I would still suggest an object with |
I agree that capabilities will be a more robust view, particularly as a lot
is defined in impl. Ex all impls will be variants.
It is fairly common (in java) to provide a version holder, which is
decoupled from packaging. However, this isn't usually directly exposed by a
type.
Where multiple tracers are possible, it is extremely important to have
something like this. Ex when you look up tracers I would expect the
metadata to include a version/features field of some sort.
|
(I also like the idea of using this to describe OpenTracing implementation support for certain perhaps-optional capabilities... examples might be formatted logging facilities or perhaps the "trace attributes" / "baggage" feature.) |
I'm closing it per the discussion in opentracing/opentracing-python#16. I'm closing it as I originally opened it, but if anyone else feels strongly about this one, please just go ahead and reopen the issue! |
On some platforms, like the browser, the binding between the API and a particular tracing implementation may only occur at runtime. For future-proofing it would be good, from the start, to expose a well-defined way for the implementation (or any code for that matter) to be able to check the OpenTracing version so compatibility constraints may be verified.
I'd propose the very simple API of:
Tracer.version() string
returns the semantic version string of the OpenTracing API. In short, this meansMAJOR.MINOR.PATCH
- see semver.org for details. Note: this is the version of the OpenTracing API and is not related to the version of the tracing implementation being used.I'm proposing a string return value matching a valid semantic version. I'm lightly arguing here that piggy-backing off the existing semantic versioning standard (while a bit more complicated to parse to handle all cases) is better than proposing, say, a simpler API that returns a 3-tuple of numbers (e.g.
[major, minor, patch]
); but I'm certainly open to being convinced otherwise :)...
(Note: as a matter of practicality, I can see some argument for also exposing other details such as a standardized way to query the name of the Tracer implementation or other runtime details. However, for this particular issue, I'd like to keep the conversation targeted to whether the above API makes sense to everyone!)
The text was updated successfully, but these errors were encountered: