llm-wiki/raw/official-docs/scorecard-opentelemetry-maturity.md

---
title: OpenTelemetry — Versioning and stability (maturity levels)
source_type: official-doc
url: https://opentelemetry.io/docs/specs/otel/versioning-and-stability/
archive_url:
status: raw
confidence: high
tags: [scorecard, maturity, otel, observability, readiness, ca-skeleton, official-doc]
related_projects: [ca-skeleton]
related_branches: [feature-implementation-readiness-scorecard]
created: 2026-05-25
last_reviewed: 2026-05-27
---

# OpenTelemetry — Versioning and stability (maturity levels)

> Layer: `raw/official-docs/` — OpenTelemetry spec(versioning-and-stability) 발췌. ca-tmpl 대안 후보 "OpenTelemetry Maturity Model" 평가용.

## Parent / 활용 branch (필수)

| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| [[raw/branch-notes/feature-implementation-readiness-scorecard]] | Group G-G 대안 2 — OTel signal lifecycle (Development → Stable → Deprecated) 모델을 ca-tmpl scorecard 에 직접 차용하지 않고 wiki 승급 5단계 + 15 area binary 조합으로 분리 결정 근거 |

추가 foundational 인용:

- [[raw/project-notes/ca-skeleton-operational-contract]] — wiki 승급 5단계 (`raw → draft → reviewed → verified → published-ready`) 가 OTel 의 signal lifecycle 과 구조적 유사성 / 의미적 차이를 가진다는 비교 근거

## 컨텍스트

`feature-implementation-readiness-scorecard` 의 ca-tmpl 대안 후보 중 **"OpenTelemetry Maturity Model"** 이 있었다. OTel 은 signal/component 단위로 Development → Stable → Deprecated 단계를 둔다. 이 단계 모델을 본 skeleton 의 readiness scorecard 에 끌어올 수 있는지 평가.

## 출처 / Source

- 원본 URL: https://opentelemetry.io/docs/specs/otel/versioning-and-stability/
- 아카이브 URL: (미수집)
- 저자 / 조직: OpenTelemetry / CNCF
- 발행일: 지속적으로 갱신 (signal 별 stability 정의)
- 마지막 확인일: 2026-05-27

## 핵심 인용 / Key quotes (verbatim)

> [§Development] "While signals are in development, breaking changes and performance issues MAY occur."

> [§Development] "OpenTelemetry clients MUST NOT be designed in a manner that breaks existing users when a signal transitions from Development to Stable."

> [§Development] "Note that 'Development' status was previously called 'Experimental' in this repository. Any uses of 'Experimental' should be treated same as 'Development'."

> [§Stable] "Once a signal in Development has gone through rigorous testing, it MAY transition to Stable."

> [§Stable] "Long-term dependencies MAY now be taken against this signal."

> [§Deprecated] "Signals MAY eventually be replaced. When this happens, they are marked as deprecated."

> [§Removed] "Support is ended by the removal of a signal from the release. The release MUST make a major version bump when this happens."

> [§Major Version Bump] "Major version bumps MUST occur when there is a breaking change to a stable interface or a deprecated signal is removed."

## Claims Extracted / 추출된 주장

| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| SC-OTEL-C1 | OTel signal 이 Development 상태일 때는 breaking changes 와 performance issues 가 발생할 수 있음 (MAY) | [§Development] "While signals are in development, breaking changes and performance issues MAY occur." | `official-standard` | OTel signal lifecycle 의 Development 단계 | Development signal 을 production 에 사용하면 반드시 실패한다는 뜻 아님 — MAY 수준 경고 |
| SC-OTEL-C2 | OpenTelemetry clients 는 signal 이 Development → Stable 로 전환될 때 기존 사용자를 깨뜨리지 않는 방식으로 설계되어야 함 (MUST NOT break) | [§Development] "OpenTelemetry clients MUST NOT be designed in a manner that breaks existing users when a signal transitions from Development to Stable." | `official-standard` | OTel client library 구현자 | Development 단계 자체에서는 breaking change 가 없다는 뜻 아님 — 전환 시점만 보호 |
| SC-OTEL-C3 | "Development" status 는 이전에 "Experimental" 로 불렸으며, 'Experimental' 사용은 'Development' 와 동일하게 취급되어야 함 | [§Development] "Note that 'Development' status was previously called 'Experimental' in this repository. Any uses of 'Experimental' should be treated same as 'Development'." | `official-standard` | 명명 변경 이전 문서 / 참조 | "Development" 단계의 의미적 정의가 이전 "Experimental" 과 100% 동일하다는 보장은 본 인용 범위 밖 — 표기만 변경 |
| SC-OTEL-C4 | Development signal 이 rigorous testing 을 거치면 Stable 로 전환 가능 (MAY transition) | [§Stable] "Once a signal in Development has gone through rigorous testing, it MAY transition to Stable." | `official-standard` | Development → Stable 전환 프로세스 | rigorous testing 의 정확한 정의/기준은 본 인용 범위 밖 — committee 판단 |
| SC-OTEL-C5 | Stable signal 에 대해서는 Long-term dependencies 를 가져갈 수 있음 (MAY) | [§Stable] "Long-term dependencies MAY now be taken against this signal." | `official-standard` | Stable signal 을 사용하는 downstream | Stable signal 이 영구히 변하지 않는다는 보장 아님 — 향후 deprecation 가능 |
| SC-OTEL-C6 | Signal 은 결국 대체될 수 있으며, 그때 deprecated 로 마킹됨 | [§Deprecated] "Signals MAY eventually be replaced. When this happens, they are marked as deprecated." | `official-standard` | OTel signal lifecycle 의 deprecation 단계 | deprecation 기간의 정확한 길이는 본 인용 범위 밖 |
| SC-OTEL-C7 | Signal 이 release 에서 제거됨으로써 support 가 끝나며, 이때 release 는 major version bump 를 해야 함 (MUST) | [§Removed] "Support is ended by the removal of a signal from the release. The release MUST make a major version bump when this happens." + [§Major Version Bump] "Major version bumps MUST occur when there is a breaking change to a stable interface or a deprecated signal is removed." | `official-standard` | OTel release versioning | minor version 에서 signal 제거가 절대 없다는 보장 (단 deprecated 가 아닌 signal 제거의 경우 명확치 않음) |

## Usage Boundaries / 적용 경계

- **이 자료가 직접 증명하는 것**:
  - `SC-OTEL-C1` ~ `C7`: OTel 의 signal lifecycle 4단계 (Development / Stable / Deprecated / Removed) 의 정확한 의미, 전환 조건, 그리고 versioning 규칙
  - 명명 변경 사실 (Experimental → Development, `SC-OTEL-C3`)
- **이 자료가 증명하지 않는 것**:
  - OTel maturity model 이 운영 계약 (release-blocking gate) 에 적합한지 — 본 spec 은 API 호환성 약속이지 운영 강제력 모델 아님
  - "rigorous testing" 의 정량 기준 (테스트 커버리지 %, 사용자 수 등)
  - ca-tmpl 의 wiki 승급 5단계와 OTel 의 4단계가 의미적으로 1:1 매핑되는지 — 두 도메인은 다름 (API 호환성 vs 문서 / 운영 readiness)
  - OTel signal 단위가 ca-tmpl 의 area 단위에 적합한 단위인지
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
  - ca-tmpl 의 `verified` 단계가 OTel `Stable` 의 "Long-term dependencies MAY now be taken" (`SC-OTEL-C5`) 와 외부 산출물 허용 정책에서 의미가 유사한지의 정확한 매핑
  - OTel 의 component (e.g., SDK / API / instrumentation) 별 별도 stability 가 ca-tmpl 의 area 단위 관리에 시사점 있는지
  - major version bump 정책 (`SC-OTEL-C7`) 을 ca-tmpl 자체의 versioning 에 적용할지

## 메모 / Notes (내 프로젝트 해석)

> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

- OTel 모델 = **signal 단위 lifecycle**. 본 skeleton 의 wiki 승급 단계 (`raw → draft → reviewed → verified → published-ready`) 와 구조적 유사성 있음.
- 차이: OTel 은 **공개 API 호환성 약속** 이 강함 (long-term dependencies allowed at Stable, `SC-OTEL-C5`). 본 skeleton 은 **운영 계약 강제력** 이 강함 (release-blocking gate).
- 따라서 OTel 모델을 그대로 가져오지 않고, **wiki 승급 5단계 + 15 area binary score** 의 조합이 본 skeleton 에 맞음.
- OTel `Stable` 정의 ("Long-term dependencies MAY now be taken", `SC-OTEL-C5`) 는 본 skeleton `verified` 단계의 외부 산출물 허용 정책과 의미가 유사.

## Related / 관련

- 같은 주제 다른 official-doc:
  - [[raw/official-docs/scorecard-aws-well-architected]] — Group G-G 대안 1 (질문 기반 HRI flag)
  - [[raw/official-docs/scorecard-cis-benchmarks-slsa]] — Group G-G 대안 3 (외부 표준 점수 체계)
- 인용하는 branch:
  - [[raw/branch-notes/feature-implementation-readiness-scorecard]] — Group G-G 대안 2
- canonical contract 섹션:
  - [[raw/project-notes/ca-skeleton-operational-contract]] §27 "100점 Readiness Scorecard"
- 인용하는 wiki: (미작성)