Release v0.10.0

[MrAlias]

0.10.0 - 2020-07-28

Added

• The Zipkin exporter now has NewExportPipeline and InstallNewPipeline constructor functions to match the common pattern.
  These function build a new exporter with default SDK options and register the exporter with the global package respectively. (Unify trace and metric exporter helpers #944)

Changed

• Replace the RegisterGlobal Option in the Jaeger exporter with an InstallNewPipeline constructor function.
  This matches the other exporter constructor patterns and will register a new exporter after building it with default configuration. (Unify trace and metric exporter helpers #944)
• The trace (go.opentelemetry.io/otel/exporters/trace/stdout) and metric (go.opentelemetry.io/otel/exporters/metric/stdout) stdout exporters are now merged into a single exporter at go.opentelemetry.io/otel/exporters/stdout.
  This new exporter was made into its own Go module to follow the pattern of all exporters and decouple it from the go.opentelemetry.io/otel module. (Unify trace and metric stdout exporters #956)
• The go.opentelemetry.io/otel/api/kv/value package was merged into the parent go.opentelemetry.io/otel/api/kv package. (Remove sub-package value from kv #968)
  • value.Bool was replaced with kv.BoolValue.
  • value.Int64 was replaced with kv.Int64Value.
  • value.Uint64 was replaced with kv.Uint64Value.
  • value.Float64 was replaced with kv.Float64Value.
  • value.Int32 was replaced with kv.Int32Value.
  • value.Uint32 was replaced with kv.Uint32Value.
  • value.Float32 was replaced with kv.Float32Value.
  • value.String was replaced with kv.StringValue.
  • value.Int was replaced with kv.IntValue.
  • value.Uint was replaced with kv.UintValue.
  • value.Array was replaced with kv.ArrayValue.
• Rename Infer to Any in the go.opentelemetry.io/otel/api/kv package. (Rename kv.Infer to kv.Any (#969) #972)

Removed

• The IndexedAttribute function from the go.opentelemetry.io/otel/api/label package was removed in favor of IndexedLabel which it was synonymous with. (Remove IndexedAttribute from api/label #970)

Fixed

• Bump github.com/golangci/golangci-lint from 1.28.3 to 1.29.0 in /tools. (Bump github.com/golangci/golangci-lint from 1.28.3 to 1.29.0 in /tools #953)
• Bump github.com/google/go-cmp from 0.5.0 to 0.5.1. (Bump github.com/google/go-cmp from 0.5.0 to 0.5.1 #957)
• Use global.Handle for span export errors in the OTLP exporter. (use global handler for span export err in otlp #946)
• Correct Go language formatting in the README documentation. (README: fixup spaces on code example #961)
• Remove default SDK dependencies from the go.opentelemetry.io/otel/api package. (Decouple API from SDK #977)

[lizthegrey]

do we want to create a go.mod for the api package so people can import it by itself?

[MrAlias]

@lizthegrey: sorry, probably should have pinged you in my last comment: #977 (comment)

... [t]he idea is to add a go.mod for the sdk/ subdirectory and have the API be the main entry point to go.opentelemetry.io/otel (#964). How the restructuring of the api package will look is still not 100% nailed down, but the separation of the SDK is the main goal (#940). Still need to resolve the instrumentation package issues prior to the new SDK package (#976, #974)

Does this make sense to you?

[lizthegrey]

@lizthegrey: sorry, probably should have pinged you in my last comment: #977 (comment)

... [t]he idea is to add a go.mod for the sdk/ subdirectory and have the API be the main entry point to go.opentelemetry.io/otel (#964). How the restructuring of the api package will look is still not 100% nailed down, but the separation of the SDK is the main goal (#940). Still need to resolve the instrumentation package issues prior to the new SDK package (#976, #974)

Does this make sense to you?

It does. Do we want to ship this current set of changes as v0.10, or do we want to add that in before v0.10 is cut?

[MrAlias]

It does. Do we want to ship this current set of changes as v0.10, or do we want to add that in before v0.10 is cut?

Good question. I was hoping (similar to you #977 (comment)) to accomplish all this in a single release.

The remaining dependencies are in the instrumentation. I didn't want to make the current instrumentation into their own modules as they would likely be single release modules before they are renamed or moved to the contrib repo. And I can't move them to the contrib repo without having the STDOUT exporter published with a release.

I could try instead to clean up the instrumentation of all SDK imports here. Which would allow for the SDK to be made into a module without any cyclic dependencies from the otel package. Would that be prefered @lizthegrey?

[lizthegrey]

I could try instead to clean up the instrumentation of all SDK imports here. Which would allow for the SDK to be made into a module without any cyclic dependencies from the otel package. Would that be prefered @lizthegrey?

Yes, I think pulling out the SDK is the right thing to do, then we cut v0.10, then we refactor contrib, I think that's the right order of operations. But you're the full-time maintainer, I'm just an approver who pitches in sometimes.

[MrAlias]

I could try instead to clean up the instrumentation of all SDK imports here. Which would allow for the SDK to be made into a module without any cyclic dependencies from the otel package. Would that be prefered @lizthegrey?

Yes, I think pulling out the SDK is the right thing to do, then we cut v0.10, then we refactor contrib, I think that's the right order of operations. But you're the full-time maintainer, I'm just an approver who pitches in sometimes.

Agreed, I'll retry this after that work.