A major version release of otelmongo should be planned before bumping to 1.26.0: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/versioning-and-stability.md#semantic-conventions-stability

OTEL_SEMCONV_STABILITY_OPT_IN is not intended for already stable releases, see here.

@prestonvasquez, why was it closed?

@pellared I wasn't aware we still wanted to do this. Should I re-open the PR?

A major version release of otelmongo should be planned before bumping to 1.26.0: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/versioning-and-stability.md#semantic-conventions-stability

I do not follow why we want to create a major version of otelmongo prior bumping the semantic conventions.

I think it may make sense to coordinate the strategy of bumping the DB semconvs to the latest version at least with @XSAM who maintains https://github.com/XSAM/otelsql.

@pellared The rationale can be found here: open-telemetry/semantic-conventions#1502 (comment)

OTEL_SEMCONV_STABILITY_OPT_IN [is] for the initial unstable to stable migration, and not subsequent major version bumps from stable -> (breaking) stable

Once we bump to 1.x, OTEL_SEMCONV_STABILITY_OPT_IN is no longer usable.

@prestonvasquez, there are two things: stability of semantic conventions and stability of instrumentation library.

Once we bump to 1.x, OTEL_SEMCONV_STABILITY_OPT_IN is no longer usable.

We can still have unstable instrumentation library (v0.x) that produces stable telemetry (compliant with semantic conventions).

The OTEL_SEMCONV_STABILITY_OPT_IN is introduced to give a "user-friendly" migration path for users of both stable and unstable instrumentation libraries to migrate from legacy semantic conventions to new semantic conventions.

You can look at HTTP Instrumentation project how we want to help otelhttp users migrating from HTTP legacy semantic conventions to stable HTTP semantic conventions: https://github.com/orgs/open-telemetry/projects/87

Additional reference: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/telemetry-stability.md

@pellared

The OTEL_SEMCONV_STABILITY_OPT_IN is introduced to give a "user-friendly" migration path for users of both stable and unstable instrumentation libraries to migrate from legacy semantic conventions to new semantic conventions.

OTEL_SEMCONV_STABILITY_OPT_IN is not intended to be used with stable instrumentation libraries. It should be used when we make a breaking change in the unstable library with the guarantee that this change will be main path in the stable upgrade.

What do you propose we do?

OTEL_SEMCONV_STABILITY_OPT_IN is not intended to be used with stable instrumentation libraries

1. otelmongo is not stable. See: https://pkg.go.dev/go.opentelemetry.io/contrib/instrumentation/go.mongodb.org/mongo-driver/mongo/otelmongo?tab=versions
2. This is not true. Find "existing major version" in https://github.com/open-telemetry/semantic-conventions/blob/main/docs/non-normative/db-migration.md.

It should be used when we make a breaking change in the unstable library with the guarantee that this change will be main path in the stable upgrade.

This is exactly where we are, right?

What do you propose we do?

I propose to implement OTEL_SEMCONV_STABILITY_OPT_IN as described in https://github.com/open-telemetry/semantic-conventions/blob/main/docs/non-normative/db-migration.md.