Files

T

DongHyeonka d71669eb59 fix: 하네스 제거 및 keycloak 문서 보강

2026-07-25 12:53:13 +09:00

8.8 KiB

Raw Permalink Blame History

title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed

title

source_type

url

archive_url

status

confidence

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 단계의 외부 산출물 허용 정책과 의미가 유사.

같은 주제 다른 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: (미작성)

8.8 KiB Raw Permalink Blame History