openfv
v0.3.2
Version 0.3.0
Status: experimenteller, instabiler Entwurf
Die Softwareversionszeichenfolgen enthalten üblicherweise die folgende Semantik:
Der etablierte und weit verbreitete SEMVER-Ansatz zur semantischen Softwareversioning verwendet das Versionsnummernformat MAJOR.MINOR.PATCH mit einem Software-API-basierten Standard für inkrementierte Werte während des Softwareentwicklungsprozesses. Zusätzliche Metadaten sind üblicherweise an diese Semver-Syntax beigefügt, um die Bereitschaft der Software für den allgemeinen Gebrauch des Endbenutzers im Rahmen eines Meilensteins für den Release (z. B. v1.2.0-alpha , v1.2.0-beta , v1.2.0-rc.1 , v1.2.0-rc.2 , v1.2.0 ) anzuzeigen. Projekte, die zusammengestellte binäre Artefakte aus dem Quellcode erstellen, assoziieren häufig ein Etikett mit dem Build -Artefakt, um einen Aufzeichnungen über den Status des Quellcodes zum Bauzeit zu erstellen (z. B. ein Git -SHA1 -Hash -String).
Diese Versionungskonzepte gelten für die Entwicklung der Schriftsoftware und sind während des Entwicklungsprozesses wünschenswert. Sie sind jedoch nicht alle unter der OpenType -Schriftart -Versioning -Spezifikation definiert. STEIPLE -SALTERS -STAGES -STAGE werden in den Namen der Tabelle OpenType -Name und den Fontrevision -Datensatz der OpenType -Headtabelle zusammengestellt. Diese Aufzeichnungen werden in der unten stehenden Formatspezifikation definiert und in der SIL -Schriftentwicklung Best Practices Dokumentation (Quelle) erläutert.
Versionszeichenfolge. Sollte mit der Syntax -Version beginnen. (Oberer Fall, unterer Fall oder gemischt, mit einem Raum zwischen „Version“ und der Anzahl).
Die Zeichenfolge muss eine Versionsnummer des folgenden Formulars enthalten: ein oder mehrere Ziffern (0-9) Wert von weniger als 65.535, gefolgt von einem Zeitraum, gefolgt von einem oder mehreren Wertschöpfern von weniger als 65.535. Jeder andere Charakter als eine Ziffer beendet die Nebenzahl. Ein Charakter wie ";" ist hilfreich, um verschiedene Versionsinformationen zu trennen.
Die erste solche Übereinstimmung in der Zeichenfolge kann von der Installationssoftware zum Vergleich von Schriftartenversionen verwendet werden. Beachten Sie, dass einige Installateure möglicherweise benötigen, um mit "Version" zu beginnen, gefolgt von einer Versionsnummer wie oben.
(Quelle)
Vom Schriftart Hersteller eingestellt
(Quelle)
Die OpenType -Spezifikation definiert eine Versionsnummer als MAJOR.MINOR . Es gibt keine Spezifikation für eine PATCH / BUILD -Versionsnummer oder eine Versionsnummer -Metadaten -Saiten. Die Schriftversions -Versioning weicht aufgrund der Schriftkompilierkonvention, die keine Polsterung in MINOR Versionsnummern enthält, weiter vom SEMVER -Versionsnummer -Format ab. Dies ist zwar nicht immer der Fall in Namensdatensätzen, aber dies ist ein konsistentes Format, das im Head.Fontrevision -Datensatz verwendet wird. Die Interpretation von Versionsnummern mit diesem Ansatz ist nicht intuitiv. Die Versionsnummer -Zeichenfolgen Version 1.1 , Version 1.01 und Version 1.001 sind alle als "anders" definiert, obwohl diese Zahlen möglicherweise alle dieselbe Entwicklungsphase darstellen (dh eine Iteration über die erste große Version hinaus). Diese Unterschiede in den Versionsnummern ergeben sich aufgrund von Konventionen, die von Projektautoren festgelegt wurden, und durch die Tools, mit denen sie Schriftarten aus ihrem Quellcode kompilieren. Die OpenType -Definitionen geben kein Format an, um den Entwicklungsstatus eines Schriftprojekts im Vergleich zu seinem Versionsmeilenstein anzugeben, und definieren auch keinen Ansatz zur Aufrechterhaltung von Informationen über den Quellcodezustand zum Erstellen der Schriftart innerhalb des Schriftartifakts. Das Fehlen eines formalen Standards zur Beantwortung der oben genannten Probleme lieferte den Impuls für diese Spezifikation.
Die OpenFV -Spezifikation (Open Font Version (OpenFV)) stellt eine konforme Erweiterung des OpenType -Namens -Tabellen -Name 5 -Datensatzes und des OpenType -Leites dar. OpenFV soll als Typa -Softwareversionsstandard für die Entwicklung, Testen, Freigabe und Verwendung des Schriftkurscodes und der von der Quelle abgeleiteten Blumenartifakte ( -Schriftarten) dienen. Diese Spezifikation definiert eine Versionsnummer -String -Syntax mit semantischen Grundlagen, die informative Daten sowohl für Entwickler als auch für Benutzer verwaltet.
Die Schlüsselwörter "Muss", "nicht", "erforderlich", "", "," nicht "," sollte "," sollte nicht "," empfohlen "," May "und" optional "in diesem Dokument wie in RFC 2119 beschrieben interpretiert werden.
Versionszeichenfolgen im OpenType -Namenstabellen -ID 5 müssen als Semikolon -Abgrenzung von obligatorischen und optionalen Datenelementen definiert werden.
Die OpenFV -Spezifikationssyntax für die Substringelemente der Vollversionszeichenfolge lautet:
[Font Version Number]; [Status/State Metadata]; [Other Metadata]
Die Schriftversionszeichenfolge muss enthalten:
Die Schriftversionszeichenfolge kann beinhalten:
Das Substring der Schriftversionsnummer:
MAJOR -Ziffern (n), einen Zeitraum (U+002E), MINOR -Versionsnummer -Ziffern.MINOR und dem Semikolon enthalten sein. Die MAJOR :
Die MINOR -Versionsnummer:
MINOR keine Polsterung verwendet werden. Die MINOR muss einen Mindestwert von 000 und einen Höchstwert von 999 haben. Das staatliche Metadaten -Substring:
a-zA-Z0-9._-[ als anfänglicher Charakter und der Trennzeichen ] als endgültiger Charakter des Substrings enthalten. Die String -Inhalte in diesen Abgrenzern müssen als "Statusetikett" definiert werden. Das Statusetikett sollte 50 Zeichen oder weniger betragen.Die Status -Metadaten -Substring:
DEVRELEASE-dev-release Andere Metadaten -Substrings:
Die Schriftversionsnummer im Fontrevision -Datensatz der OpenType -Headtabelle:
MAJOR -Ziffern (en), ein Zeitraum, MINOR Versionsnummer -Ziffern definiert werdenMINOR Versionsnummer haben, die genau drei Ziffern in Länge beträgt. Für MINOR Versionsnummern von weniger als 100 muss Zero Padding verwendet werden. Die MINOR muss einen Mindestwert von 000 und einen Höchstwert von 999 haben.MAJOR oder nach der MINOR enthaltenMAJOR.MINOR -Versionsnummer soll einen Meilenstein für die Freigabe darstellen, der möglicherweise unvollständig in der Quelle implementiert wird, die mit einer MAJOR.MINOR -Versionsnummer definiert ist. Die MAJOR.MINOR -Versionsnummer dürfte nicht den Quellcode -Zustand zum Bauzeit in Build -Artefakten darstellen und möglicherweise nicht einzigartig für Build -Artefakte sind, da die Arbeiten für einen Meilenstein für MAJOR.MINOR -Version durchgeführt werden.MAJOR sollte während der Vorproduktionsphase der Entwicklung vor der Erstveröffentlichung auf 0 eingestellt werden. MAJOR 0 zeigt diese Entwicklungsphase vor der Produktion an.MAJOR muss zum Zeitpunkt der Erstveröffentlichung an Endbenutzer auf 1 gesetzt werden. Die Konvertierung von der MAJOR 0 in MAJOR Hauptversionsnummer 1 zeigt die Bestätigung der Autoren an, dass Quellcode und Build -Artefakte die OpenFV -Release -Definition erfüllen.Die Semantik für Änderungen an der Versionsnummer muss ein Inkrement nach dem Wert von 1 der:
MAJOR für den Abschluss der wichtigsten projektspezifischen Meilensteine und aller inkompatiblen Änderungen an der Schriftsoftware (z. B. die Beseitigung der Unterstützung für einen gesamten Unicode-Code-Bereich).MINOR Versionsnummer für Funktionen, Hotfix und Abhängigkeitsänderungen. Beispiele sind: Wenn die MAJOR inkrementiert ist, wird die MINOR in einen Wert von 000 geändert.
Beispiele für Namenstabelle ID 5 Datensatzversionszeichenfolgen, die der OpenFV -Spezifikation erfüllen, gehören:
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
Beispiele für Headtable Fontrevision -Datensatzversionszeichenfolgen, die der OpenFV -Spezifikation erfüllen, umfassen:
1.001
10.010
100.100
CC um 4.0
