Skip to content

Discuss possible stable+incubating solutions for semconv artifacts #50

@lmolkova

Description

@lmolkova

Extracted from #45

Repeating the question I left on the python PR open-telemetry/opentelemetry-python#3586 (comment)

Option 1: ship 2 artifacts (semconv and semconv-incubating) - current solution

It's aligned with semantic versioning, easy to maintain.
Still having stable attributes as deprecated in the incubating artifact is not great.

Option 2: ship 1 artifact, but two different versions: stable and preview. Stable contains only stable semconv. Preview contains all of them.

Ideal in terms of semantic versioning. When attribute stabilizes, it remains in the same namespace and all libs/apps that depend on it don't need to change
The only downside is that it could be harder to maintain and release.

Option 3: Probably not applicable to Java - ship 1 artifact, 1 version containing stable and experimental semconv. Emphasize that some parts are experimental via namespace (import semconv.experimental.foo_attributes, perhaps we should call it _experimental )?

It's easy to do, but violates semantic versioning. When attribute stabilizes, it moves to a different namespace, i.e. libs/apps that depend on it need to change.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions