Skip to content
This repository has been archived by the owner on May 23, 2023. It is now read-only.

add a OT-Go semver #51

Closed
wants to merge 3 commits into from
Closed

add a OT-Go semver #51

wants to merge 3 commits into from

Conversation

bhs
Copy link
Contributor

@bhs bhs commented Feb 11, 2016


// ImplementationID is a simple, extensible struct that describes an
// OpenTracing implementation.
type ImplementationID struct {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(the only interesting part of this change)

@bhs
Copy link
Contributor Author

bhs commented Feb 11, 2016

This intentionally does not handle any notion of Capabilities... Upon reflection I'd like to see the APIs used more in the wild first.


// Version may take any form, but SemVer (http://semver.org/) is strongly
// encouraged.
Version string
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bensigelman , this looks pretty good, but Go seems a bit like the exceptional case with regards to the utility of a version string (since everything in Go is basically statically bound). I'm curious what this might look like for Python. I'm specifically considering the case where the supported version of the OpenTracing standard is what's of interest rather than the underlying implementation version. E.g. if an arbitrary piece of Python code is handed a tracer object, how can it (cleanly) check the supported version of OpenTracing on that object?

(By the way I believe I'm safe in assuming that in the above Version is intended to represent the implementation version given the struct name and the "may take any form" comment.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @bcronin, it's the OpenTracing version that the original ticket was asking for. We said it would be best done via Capabilities API rather than a version. At the moment, however, there doesn't seem to be any aspects of the API that are optional and require introspection by the client code.

@bhs
Copy link
Contributor Author

bhs commented Feb 11, 2016

@bcronin @yurishkuro roger that... makes sense. I added a const here for the Go OpenTracing version, and I sent out opentracing/opentracing-python#16 for python...

return standardtracer.New(NewTrivialRecorder(processName))
return standardtracer.New(
NewTrivialRecorder(processName),
&opentracing.ImplementationID{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you're explicitly letting tracers return nil here? Doesn't seem like a bad idea to force tracers to pick a name and version.

@bhs
Copy link
Contributor Author

bhs commented Feb 11, 2016

Per opentracing/opentracing-python#16, I'm pulling this back to be a semver for the Go API and nothing else.

@bhs bhs changed the title add the notion of a ImplementationID add a OT-Go semver Feb 11, 2016
@bhs
Copy link
Contributor Author

bhs commented Feb 15, 2016

(withdrawing this per opentracing/opentracing.io#33)

@bhs bhs closed this Feb 15, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants