SPECIFICATION

제10장 버전 관리

권위 있는 출처 선언(Single Source of Truth). DTP 버전 관리의 정책은 제1장 §1.7 「버전 관리와 호환성」을 유일한 권위 있는 출처로 한다. 본 장은 §1.7이 이미 규정한 정책을 재정의해서는 안 된다. 본 장은 §1.7 규칙의 작동 메커니즘(와이어 포맷 바인딩, 오류 코드의 구체적 페이로드, 협상 시퀀스, 구현 선언 템플릿)과 거버넌스 흐름(디렉터리와 상태 규약, 확정 표준 동작)만을 제공한다. 본 장의 어떠한 진술이 §1.7과 모호한 경우, 반드시 §1.7을 우선해야 한다.

10.1 버전 번호 형식(작동 참조)

DTP 프로토콜 버전 번호의 의미, 2단계 MAJOR.MINOR 구조(PATCH 없음), 변경 판정 규칙, 직교 축 정의는 §1.7.1 및 §1.7.2에 있으며, 본 장에서는 반복하지 않는다.

와이어 포맷 바인딩: 각 LogicalFrame의 프레임 헤더는 완전한 ProtocolVersion 필드를 포함해야 한다(제4.4절 참조):

interface ProtocolVersion {
  major: number;  // 음이 아닌 정수
  minor: number;  // 음이 아닌 정수
}

본 사양이 정의하는 프로토콜의 초기 버전은 { major: 1, minor: 0 }(즉 dtp/1.0)이어야 한다.

10.2 버전 호환성 매트릭스(§1.7.3의 작동 보충)

호환성과 협상의 규범적 규칙은 §1.7.3에 있다. 아래 표는 프레임 처리 수준에서의 그 작동적 구현이며, §1.7.3에 따라 읽어야 한다. 모호한 경우 §1.7.3을 우선한다.

수신 프레임 버전	처리 방식
수신측 최고 버전과 동일	정상 처리
수신측 최고 버전의 이전 메이저 버전(major - 1)과 동일	호환 처리(이전 사양에 따라 처리)
수신측 최고 버전보다 높음	`VERSION_INCOMPATIBLE`(7001)을 반환해야 한다
(수신측 최고 버전 - 1)보다 낮은 메이저 버전	`VERSION_INCOMPATIBLE`(7001)을 반환해야 한다
동일 메이저 버전, 더 낮은 마이너 버전	정상 처리(하위 호환)
동일 메이저 버전, 더 높은 마이너 버전	처리해야 한다(권장)(인식하지 못하는 선택 필드는 무시)

10.2.1 마이너 버전 번호 관용성(§1.7.3의 작동적 구현)

구현이 메이저 버전은 동일하지만 마이너 버전이 더 높은 프레임을 수신할 때 다음을 충족해야 한다:

알려진 필드를 처리한다;
알 수 없는 선택 필드를 무시해야 한다(권장);
알 수 없는 선택 필드 때문에 전체 프레임을 거부해서는 안 된다;
오류를 발생시켜서는 안 된다.

10.3 버전 비호환 처리(작동 메커니즘)

10.3.1 수신측 처리

수신측이 자체 지원 버전보다 프로토콜 버전이 높은(그리고 호환 범위를 벗어난) LogicalFrame을 받을 때 다음을 수행해야 한다:

해당 프레임을 처리하지 않는다;
송신측에 VERSION_INCOMPATIBLE 오류(7001)를 전송한다;
오류 통지의 details 필드에 자체 지원하는 최고 버전 번호를 포함한다:

{
  errorCode: 7001,
  errorMessage: "Protocol version higher than supported",
  details: {
    supportedMaxVersion: { major: 1, minor: 0 }
  }
}

오류 코드 7001의 의미는 제9장 오류 코드 표와 schema를 기준으로 하며, 본 장에서는 별도로 정의하지 않는다.

10.3.2 송신측 처리

송신측이 VERSION_INCOMPATIBLE 오류를 받은 후 다음을 선택할 수 있다:

상대측 지원 버전으로 다운그레이드하여 해당 프레임을 다시 전송(우선해야 함(권장). 단, 양측에 공통 MAJOR가 존재하는 것을 전제로 함; MAJOR를 넘는 다운그레이드는 하지 않음, §1.7.3 참조);
상위 애플리케이션에 통지하여 버전 비호환을 알리고, 자동으로 지속적으로 재시도해서는 안 된다.

구현은 버전 비호환 오류를 받은 직후 세션을 닫아서는 안 되며, 다운그레이드 기회를 주어야 한다(권장).

10.3.3 세션 내 버전 일치성과 협상 시퀀스

DTP 세션 수립 시 양측은 일치된 프로토콜 버전을 협상해야 한다(협상 규칙은 §1.7.3에 있음). 세션 기간 동안:

협상 후 전체 세션 기간 동안 통일된 버전을 사용해야 한다;
세션 진행 중 프로토콜 버전을 전환해서는 안 된다.

버전 협상은 다음 시퀀스를 따라야 한다(권장). 구체적 담지 방식(CAP 확장, 첫 번째 Request_Frame/Response_Frame 등)은 구현이 선택할 수 있으나, 첫 번째 데이터 프레임 전송 전에 완료해야 한다:

DTP_A                              DTP_B
  |                                   |
  |-- Hello (supported_versions) --->|
  |                                   |
  |<-- Hello_Ack (chosen_version) ---|
  |                                   |
  |    [양측이 chosen_version 사용]    |

10.4 프로토콜 진화와 거버넌스

본 절은 §1.7 거버넌스 규칙의 작동 흐름을 제공한다. 거기서 언급되는 git tag 형식, 문서 상태 열거형, 편집 판차 정의는 §1.7을 규칙 앵커로 삼아야 하며, 본 절에서는 재정의하지 않는다.

10.4.1 디렉터리와 상태 규약(Faying Protocol과 일치)

문서 상태는 front matter 마커이며, 경로에 인코딩해서는 안 된다(§1.7.1 참조).
specification/ 아래에는 유일한 가변 작업 영역 draft/만 유지해야 한다(롤링 업데이트).
draft/ 이외의 모든 디렉터리는 배포 일자로 명명해야 하며(예: 2025-10-25/), 동결된 배포 판차를 나타낸다. 「초안이 아니면 배포됨」.
어떤 배포 판차가 현재 Final인지 Deprecated / Obsolete인지는 오직 그 파일의 status 필드로 결정되며, 디렉터리명으로 추론해서는 안 된다.
상태로 명명한 디렉터리(예: final/) 생성은 금지된다——그렇지 않으면 판차를 폐지할 때 디렉터리 이동과 링크 파괴가 필요해진다.
WHEN 상태 전이가 발생하면, 오직 front matter의 status만 수정해야 하며, 디렉터리는 이동해서는 안 된다.

10.4.2 초안과 정식 버전

초안: 문서는 docs/{lang}/specification/draft/에, schema는 schema/draft/에 저장한다; 초안 버전 번호는 { major: 0, minor: N }을 사용할 수 있다. Draft 기간 중에는 호환성 약속이 없으며(§1.7.5 참조), 초안을 운영 환경에서 사용해서는 안 된다.
정식 버전: 완전한 검토와 공개 토론을 거쳐 불변의 버전 스냅샷을 가져야 한다; 문서는 docs/{lang}/specification/{YYYY-MM-DD}/에, schema는 schema/{YYYY-MM-DD}/에 저장한다. 첫 번째 정식 버전은 2025-10-25이며, 프로토콜 버전 dtp/1.0에 대응한다.
버전 스냅샷 불변성: 정식 버전은 일단 배포되면 불변을 유지해야 한다; 순수 텍스트 정오는 §1.7.4에 따라 새로운 배포 일자 디렉터리로 담으며, 기존 디렉터리는 동결되고, 배포된 스냅샷의 사양 내용이나 schema를 제자리에서 다시 써서는 안 된다.

10.4.3 확정 표준 동작(Draft → Final)

WHEN 확정을 수행할 때, Doc Governance Process는 다음 동작을 순서대로 완료해야 한다:

git mv로 draft/ 아래 모든 파일을 배포 일자 디렉터리로 이전하고(파일명 불변), draft/를 비운다;
파일별로 status를 Draft에서 Final로 변경한다;
date를 정식 배포 일자로 고정하고, editors를 확정 서명 명단으로 잠그며, version을 불변으로 유지한다;
README front matter에 replaces 이력 체인(초안 디렉터리 및 그 확정 커밋 짧은 해시를 가리킴)을 기입한다;
tag dtp-v<MAJOR.MINOR>-final을 설정한다. 이 tag는 본문 + 테스트 벡터 + schema를 동시에 커버해야 한다;
다국어 / 다중 파일이 관련된 경우, 동일한 커밋에서 함께 이전해야 하며, 일방적 배포는 금지된다.

10.4.4 폐지와 제거

구현은 다음 절차를 통해 기능을 폐지해야 한다(권장):

폐지 표시: MINOR 버전에서 기능을 deprecated로 표시하되, 계속 지원해야 한다;
전이 기간: 적어도 하나의 완전한 MAJOR 버전 주기를 거친다;
제거: 다음 MAJOR 버전에서 제거한다.

구현은 MINOR 버전에서 폐지된 기능을 제거해서는 안 된다.

10.5 구현 선언

DTP 구현은 문서에서 다음을 선언해야 한다:

지원하는 최고 프로토콜 버전;
지원하는 모든 이전 메이저 버전;
미래 호환성 지원 여부(더 높은 마이너 버전의 프레임 처리);
구현 정의 확장(있을 경우).

예시:

DTP 구현 X 버전 선언:

지원하는 최고 프로토콜 버전: 1.0

호환되는 이전 버전: 없음(첫 번째 정식 버전)

미래 호환성: 지원, 알 수 없는 선택 필드는 무시됨

암호화 알고리즘: AES-256-GCM, ChaCha20-Poly1305

전송 어댑터: BLE, WebSocket, TCP