
버전 0.3.0
상태 : 실험적이고 불안정한 초안
소프트웨어 버전 문자열은 일반적으로 다음 의미를 포함합니다.
시맨틱 소프트웨어 버전 설정에 대한 확립되고 널리 사용되는 SEMVER 접근 방식은 소프트웨어 개발 프로세스 중에 증분 값에 대한 소프트웨어 API 기반 표준과 함께 버전 번호 형식 MAJOR.MINOR.PATCH 사용합니다. 추가 메타 데이터는 일반적 으로이 SEMVER 구문에 추가되어 최종 사용자의 일반적인 사용을위한 소프트웨어의 준비가 릴리스 이정표 (EG v1.2.0-alpha , v1.2.0-beta , v1.2.0-rc.1 , v1.2.0-rc.2 , v1.2.0 )를 나타냅니다. 소스 코드에서 컴파일 된 이진 아티팩트를 생성하는 프로젝트는 종종 빌드 아티팩트와 레이블을 연결하여 빌드 시간에 소스 코드 상태의 레코드를 설정합니다 (예 : Git Commit SHA1 HASH String).
이러한 버전 관리 개념은 서체 소프트웨어 개발에 적용되며 개발 프로세스 중에 바람직합니다. 그러나 OpenType 글꼴 버전 설정 사양에 따라 모두 정의되지는 않습니다. 서체 표면 소프트웨어 버전 문자열은 OpenType 이름 테이블의 NameID 5 레코드와 OpenType 헤드 테이블의 Fontrevision 레코드로 컴파일됩니다. 이 레코드는 다음과 같이 OpenType 형식 사양으로 정의되며 SIL Font Development 모범 사례 문서 (Source)에 설명되어 있습니다.
버전 문자열. 구문 '버전'으로 시작해야합니다. (“버전”과 숫자 사이의 공간이있는 대문자, 소문 또는 혼합).
문자열에는 다음 형식의 버전 번호가 포함되어야합니다. 65,535보다 작은 숫자의 숫자 (0-9), 기간이 뒤 따른 다음 65,535보다 작은 값의 숫자가 이어집니다. 숫자 이외의 다른 문자는 작은 숫자를 종료합니다. ";"와 같은 캐릭터 다른 버전 정보를 분리하는 데 도움이됩니다.
문자열의 첫 번째 일치는 설치 소프트웨어에서 글꼴 버전을 비교하기 위해 사용할 수 있습니다. 일부 설치 업체는 문자열이 "버전"으로 시작하고 위와 같이 버전 번호가 필요할 수 있습니다.
(원천)
글꼴 제조업체가 설정했습니다
(원천)
OpenType 사양은 버전 번호를 MAJOR.MINOR 로 정의합니다. PATCH / BUILD 버전 번호 또는 버전 번호 메타 데이터 문자열에 대한 사양이 없습니다. 글꼴 버전화는 글꼴 컴파일러 컨벤션의 결과로 Semver 버전 번호 형식에서 더 멀리 떨어져있어 MINOR 버전 번호로 패딩이 제로를 포함합니다. Nameid 5 레코드에서 항상 그런 것은 아니지만 Head.Fontrevision 레코드에 사용되는 일관된 형식입니다. 이 접근법으로 버전 번호의 해석은 직관적이지 않습니다. 버전 번호 문자열 Version 1.1 , Version 1.01 및 Version 1.001 은 모두 "다른"으로 정의되지만이 숫자는 모두 동일한 개발 단계 (즉, 첫 번째 주요 릴리스를 넘어서 하나의 반복)를 나타낼 수 있습니다. 이러한 버전 번호의 차이는 프로젝트 저자 (들)와 소스 코드에서 글꼴을 컴파일하는 데 사용하는 도구에 의해 설정된 규칙으로 인해 발생합니다. OpenType 정의는 버전 이정표에 비해 서체 프로젝트의 개발 상태를 나타내는 형식을 지정하지 않으며 글꼴 빌드 아티팩트 내에서 빌드 시간에서 소스 코드 상태에 대한 정보를 유지하는 접근 방식을 정의하지 않습니다. 위의 문제를 해결하기위한 공식적인 표준이 없으면이 사양에 대한 자극이 제공되었습니다.
Open Font 버전 (OpenFV) 사양은 OpenType Name Table Nameid 5 레코드 및 OpenType Head.fontrevision 레코드 사양의 준수 확장을 나타냅니다. OpenFV는 서체 소스 코드의 개발, 테스트, 릴리스 및 사용을위한 서체 소프트웨어 버전화 표준으로 사용되며 소스에서 파생 된 글꼴 (Font). 이 사양은 개발자와 사용자 모두에게 유익한 데이터를 유지하는 시맨틱 토대가있는 버전 번호 문자열 구문을 정의합니다.
"필수", "필수", "필수", "해야한다", "해야 할 것", "해야 할 것", "해야 할 것", "권장", "권장", "may"및 "선택 사항"은 RFC 2119에 설명 된대로 해석되어야한다.
OpenType 이름 테이블 ID 5 레코드의 버전 문자열은 필수 및 선택적 데이터 요소의 세미콜론 구분 하위 문자로 정의되어야합니다.
정식 버전 문자열의 하위 문자열 요소에 대한 OpenFV 사양 구문은 다음과 같습니다.
[Font Version Number]; [Status/State Metadata]; [Other Metadata]
글꼴 버전 문자열에는 다음을 포함해야합니다.
글꼴 버전 문자열에는 다음이 포함될 수 있습니다.
글꼴 버전 번호 하위 문자 :
MAJOR 버전 번호 자리 (들), 기간 (u+002E), MINOR 버전 번호 숫자로 정의해야합니다.MINOR 버전 번호와 세미콜론 사이에 공백 문자를 포함해서는 안됩니다. MAJOR 버전 번호 :
MINOR 버전 번호 :
MINOR 버전 번호로 사용해야합니다. MINOR 버전 번호의 최소값은 000이고 최대 값은 999이어야합니다. State Metadata Substring :
a-zA-Z0-9._-[ 초기 문자 및 구분 기자 ] 를 포함해야합니다. 이 구분자 내부의 문자열 내용은 "상태 레이블"으로 정의되어야합니다. 상태 레이블은 50 자 이하이어야합니다.상태 메타 데이터 하위 문자 :
DEVRELEASE-dev-release 기타 메타 데이터 기판 :
OpenType 헤드 테이블의 Fontrevision 레코드의 글꼴 버전 번호 :
MAJOR 버전 번호 숫자, 기간, MINOR 버전 번호 숫자로 정의해야합니다.MINOR 버전 번호가 있어야합니다. 100 미만의 MINOR 버전 번호의 경우 제로 패딩을 사용해야합니다. MINOR 버전 번호의 최소값은 000이고 최대 값은 999이어야합니다.MAJOR 버전 번호 앞이나 MINOR 버전 번호 앞에 문자를 포함해서는 안됩니다.MAJOR.MINOR 버전 번호는 MAJOR.MINOR 버전 번호로 정의 된 소스에서 불완전하게 구현 될 수있는 릴리스 이정표를 나타 내기위한 것입니다. MAJOR.MINOR 버전 번호는 빌드 아티팩트에서 빌드 시간에 소스 코드 상태를 나타내는 것이 아니며 MAJOR.MINOR 버전 이정표를 달성하기 위해 작업이 수행되므로 빌드 아티팩트에서 독특하지 않을 수 있습니다.MAJOR 버전 번호는 0으로 설정해야합니다. MAJOR 버전 번호 0 은이 사전 생산 단계를 나타냅니다.MAJOR 버전 번호는 최초 릴리스 시점에 최종 사용자에게 1으로 설정해야합니다. MAJOR 버전 번호 0에서 MAJOR 버전 번호 1으로 변환하면 소스 코드 및 빌드 아티팩트가 OpenFV 릴리스 정의를 충족한다는 저자의 승인을 나타냅니다.버전 번호 변경에 대한 의미론에는 1의 값에 의한 증분이 포함되어야합니다.
MAJOR 버전 번호 및 서체 소프트웨어에 대한 모든 후진 호환 변경 (예 : 전체 유니 코드 코드 범위에 대한 지원 제거).MINOR 버전 번호. 예제는 다음과 같습니다. MAJOR 버전 번호가 증가하면 MINOR 버전 번호는 000 값으로 변경됩니다.
OpenFV 사양을 충족하는 이름 테이블 ID 5 레코드 버전 문자열의 예는 다음과 같습니다.
Version 1.001
Version 1.001; DEV
Version 1.001; RELEASE
Version 1.001; [abcd123]
Version 1.001; [abcd123]-dev
Version 1.001; [abcd123]-release
Version 1.001; [abcd123]-dev; here are metadata
Version 1.001; [abcd123]-release; here are metadata
Version 1.001; here are metadata
Version 1.001; here are metadata; here are more metadata
OpenFV 사양을 충족하는 헤드 테이블 Fontrevision 레코드 버전 문자열의 예는 다음과 같습니다.
1.001
10.010
100.100
CC x 4.0