Decide what to do about deprecated zipkin exporter and stability

[jack-berg]

Zipkin span exporter is deprecated: open-telemetry/opentelemetry-specification#4715

If we go stable with a stable ZipkinSpanExporter type, we'll be stuck with it indefinitely, long after the corresponding spec has been deleted.

One option is to make it experimental, i.e. change the type to ExperimentalZipkinSpanExporter, and change referencing it to use zipkin/development:

tracer_provider:
  processors:
    - batch:
        exporter:
          zipkin/development:
            endpoint: ...

[marcalff]

For Zipkin, we are lucky that the deprecation is announced before the schema is declared stable. In this case, I think the schema should remove zipkin alltogether, forcing users to adjust sooner before rolling out declarative configuration, rather than later in production. If this is too hash, see the general case below.

Now, assuming the schema is declared stable at some point, and that item "foo" is later declared deprecated in the spec, the question still stands: how to we plan to address that ?

Changing the name from foo to foo/development or better foo/deprecated is by itself a breaking change, since existing configurations using just foo will fail, so the name must remain foo.

Yet declarative configuration still needs to convey somehow the deprecation status, so users can plan accordingly.

I propose to add a new status, deprecated, in meta_schema_language_{lang}.yaml to represent deprecation of a property.

[jack-berg]

In this case, I think the schema should remove zipkin alltogether, forcing users to adjust sooner before rolling out declarative configuration, rather than later in production. If this is too hash, see the general case below.

Given that declarative config is still not stable and probably not widely adopted, there's a chance that there are zero users with zipkin and declarative config. I think we ought to delete the zipkin type, and bring it back as zipkin/development / zipkin/deprecated if we receive any user feedback suggesting it was being used.

I propose to add a new status, deprecated, in meta_schema_language_{lang}.yaml to represent deprecation of a property.

JSON schema has a deprecated annotation we can use as well.

The compile-schema make target could be updated to enrich property description with a deprecation notice if present.

The generate-markdown make target could be updated to add a warning to deprecated types and properties.

This doesn't speak to whether or not we need to independently track it at the language level.

[marcalff]

Given that declarative config is still not stable and probably not widely adopted, there's a chance that there are zero users with zipkin and declarative config. I think we ought to delete the zipkin type, and bring it back as zipkin/development / zipkin/deprecated if we receive any user feedback suggesting it was being used.

Sounds good to me.