[OpenFontLibrary] MajorVersion MinorVersion

[Eric Schrijver]

On 23-09-13 12:12, Grzegorz Rolek wrote:
> On Sep 23, 2013, at 10:07 AM, Eric Schrijver wrote:
>
>> On 23-09-13 08:06, Khaled Hosny wrote:
>>> On Sun, Sep 22, 2013 at 11:24:34PM +0200, Eric Schrijver wrote:
>>>> Majorversion Minorversion (ints) is rather restrictive (I like to
>>>> have Major Minor Patch version) And I remember some story about
>>>> windows not handeling Majorversion < 1 correctly?
>>>>
>>>> A proper free font takes it time before reaching version 1 :)
>>> I have been releasing fonts with < 1 version all the time, no issues
>>> were reported related to this (though I don’t use UFO and have no idea
>>> what its versions map to in SFNT fonts).
>>>
>>> Regards,
>>> Khaled
>> Hey Khaled.
>>
>> Thanks. So I guess I am a bit lost here. My more general question, I think, is in FontForge, what are the different kind of versions I can set, what are their limitations, and what do map to in an OTF?
>>
>> I remember I found something of a MajorVersion MinorVersion dialog in FontForge (that warned me when I set the Major Version to 0). But it is no longer there.
>>
>> For now there is:
>>
>> PS NAMES -> Version
>> PS NAMES -> sfnt Revision
>> TTF NAMES -> Version
>>
>> These are all strings no?
>>
>> When I open my UFO, only TTF Names -> Version is set. This is also the version I see when I create an OTF and open it with Gnome’s font preview [1].
> PostScript's version entry technically is a string, but from the very beginning it had a strong convention of being a compound of two, point-separated, three-digit numbers, that could be thought of as being a major/minor versioning. Font revision field in SFNT is a fixed-point number in all likelihood meant to be a major/minor scheme also. For both font formats those entries would be the best mapping for your major and minor numbers, I suppose.
>
> The name-related version entry you see in a font preview is a string for display purposes only and can contain any textual data. Still, it's often being filled with some form of parseable version numbers, and could be the only reasonable place for a non-standard versioning scheme.
>
So having a Major and Minor version number is more or less the standard 
for fonts?

I can imagine that works in the context of traditional foundries that 
don’t release a lot of versions of fonts, but with a ‘release early 
release often’ mindset I figured you might need more than that…
Like I said I personally like having Major.Minor.Patch, with the minor 
versions resembling discrete goals, and the patch versions incremental 
progress towards these goals.
For me the major version represents an overarching design direction 
(once it reaches 1.0, the fonts’ primary design goals are reached).

How do other Open Source font projects deal with their version numbers? 
Any best practices?

Heart,
e