Semconv schema: add a field to record a version attribute was added in

[lmolkova]

It could be useful in code documentation - e.g. it's a common practice in Java to add @since annotation (helps when debugging version conflicts and other similar problems).

Also, there could be cases when we need conflict resolution based on this property open-telemetry/semantic-conventions-java#75 (comment)

[arminru]

Weaver would be able to also determine this programmatically by walking through the schemas folder without having to introduce a dedicated field, right? cc @lquerel

[trask]

Weaver would be able to also determine this programmatically by walking through the schemas folder without having to introduce a dedicated field, right? cc @lquerel

the schemas folder currently only includes attributes that have a schema transformation, or is this a new proposal where we include the full set of attributes in the schema?

[lmolkova]

I believe the proposal is to resolve multiple versions at the same time and populate metadata based on git history.

If we go down this route, we can as well cache it somewhere (maybe separately from semconv yaml files) to avoid resolving all past versions or adding versions manually.

[lquerel]

Once the schema format for the resolved registries is fixed and approved, we could indeed archive a file per registry version. This approach has the advantage of: 1) allowing Weaver to quickly compare versions and infer attributes like 'since'; 2) enabling external tools to access registries easily without reinventing the wheel regarding resolution. The resolved format, no longer having references, extends, embeds, etc., will also be more robust to this type of semconv author oriented field.

However, I think a field is missing at the attribute level that identifies if an attribute 'x' is the result of renaming an attribute 'y'. Without this information, it is IMO not possible to distinguish between a renaming and a deletion of an attribute and the creation of another unrelated attribute. We could use transformations in the telemetry schema, but I believe the idea was to generate these schemas automatically from Weaver. Therefore, it is necessary to have a field at the attribute level in the semconv group.

EDIT: adding @jsuereth