openfv
v0.3.2
バージョン0.3.0
ステータス：実験的、不安定なドラフト
ソフトウェアバージョン文字列には、一般的に次のセマンティクスが含まれます。
セマンティックソフトウェアバージョンへの確立され広く使用されているSEMVERアプローチは、バージョン番号形式MAJOR.MINOR.PATCHを使用して、ソフトウェア開発プロセス中に増分値のソフトウェアAPIベースの標準を使用します。追加のメタデータは、このsemver構文に一般的に追加されており、作業がリリースマイルストーンに向かって進行するにつれて、エンドユーザーが一般的に使用するソフトウェアの準備を示しています（例： v1.2.0-alpha 、 v1.2.0-beta 、 v1.2.0-rc.1 、 v1.2.0-rc.2 、 v1.2.0 ）。ソースコードからコンパイルされたバイナリアーティファクトを作成するプロジェクトは、頻繁にラベルをビルドアーティファクトに関連付けて、ビルド時にソースコードの状態の記録を確立します（たとえば、gitコミットSHA1ハッシュ文字列）。
これらのバージョン化の概念は、書体ソフトウェアの開発に適用され、開発プロセス中に望ましいです。ただし、それらはすべてOpenTypeフォントバージョンの仕様で定義されているわけではありません。書体ソフトウェアバージョン文字列は、Opentype名のテーブルのNameID 5レコードとOpentypeヘッドテーブルのfontrevisionレコードにコンパイルされます。これらのレコードは、以下のOpentype形式の仕様で定義されており、SILフォント開発ベストプラクティスドキュメント（ソース）で説明されています。
バージョン文字列。構文「バージョン」から始める必要があります。 （「バージョン」と数の間のスペースを持つ、大文字、小文字、または混合）。
文字列には、次の形式のバージョン番号が含まれている必要があります。65,535未満の値の1桁以上（0-9）、続いて65,535未満の値の1桁以上の値です。数字以外の文字は、マイナー数を終了します。 「;」などのキャラクターさまざまなバージョン情報を分離するのに役立ちます。
文字列の最初のそのような一致は、インストールソフトウェアでフォントバージョンを比較するために使用できます。一部のインストーラーは、「バージョン」で開始するために文字列を必要とし、その後に上記のようにバージョン番号が必要になる場合があることに注意してください。
（ソース）
フォントメーカーによって設定されています
（ソース）
Opentype仕様は、バージョン番号をMAJOR.MINORとして定義します。 PATCH / BUILDバージョン番号やバージョン番号メタデータ文字列の仕様はありません。 Fontバージョン化は、フォントコンパイラコンベンションの結果として、SEMVERバージョン番号形式からさらに逸脱して、 MINORバージョン番号にゼロパディングを含めます。これは、NameID 5レコードでは常にそうであるとは限りませんが、これはhead.fontrevisionレコードで使用される一貫した形式です。このアプローチを使用したバージョン番号の解釈は直感的ではありません。バージョン番号文字列Version 1.1 、 Version 1.01 、およびVersion 1.001はすべて「異なる」と定義されていますが、これらの数値はすべて同じ開発段階を表している可能性があります（つまり、最初の主要リリースを超えた1つの反復）。バージョン数のこれらの違いは、プロジェクト著者によって確立された慣習と、ソースコードからフォントをコンパイルするために使用するツールによって出現します。 Opentypeの定義は、バージョンのマイルストーンに関連する書体プロジェクトの開発ステータスを示す形式を指定しておらず、フォントビルドアーティファクト内のビルド時にソースコード状態に関する情報を維持するアプローチも定義しません。上記の問題に対処するための正式な基準の欠如は、この仕様の推進力を提供しました。
Open Fontバージョン（OpenFV）仕様は、Opentype名のテーブル名5録画5レコードとOpentype head.Fontrevisionレコード仕様の準拠の拡張機能を表します。 OpenFVは、Sourceから派生した書体ソースコードとビルドアーティファクト（フォント）の開発、テスト、リリース、および使用のための書体ソフトウェアバージョン標準として機能することを目的としています。この仕様では、開発者とユーザーの両方に有益なデータを維持するセマンティックの基盤を持つバージョン番号文字列構文を定義します。
「必須」、「必須」、「必須」、「「しなければ」、「そうしない」、「そうではない」、「そうはならない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119に記載されていると解釈されます。
Opentype名のバージョン文字列テーブルID 5レコードは、必須およびオプションのデータ要素のセミコロン区切りサブストリングとして定義する必要があります。
フルバージョン文字列のサブストリング要素のOpenFV仕様構文は次のとおりです。
[Font Version Number]; [Status/State Metadata]; [Other Metadata]
フォントバージョンの文字列には以下を含める必要があります。
フォントバージョンの文字列には以下が含まれます。
フォントバージョン番号サブストリング：
MAJORバージョン数桁、期間（U+002E）、 MINORバージョン数桁として定義する必要があります。MINORバージョン番号とセミコロンの間には、Whitespace文字を含めないでください。 MAJORバージョン番号：
MINORバージョン番号：
MINORバージョン番号で使用する必要があります。 MINORバージョン番号の最小値は000、最大値は999です。 状態メタデータサブストリング：
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リリースの定義を満たしているという著者の承認を示します。バージョン番号の変更のセマンティクスには、次の値の値による増分を含めるものとします。
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 RECORDバージョン文字列の例は次のとおりです。
1.001
10.010
100.100
CC by 4.0
