[OpenFontLibrary] MajorVersion MinorVersion

Eric Schrijver eric at authoritism.net
Mon Sep 23 07:30:47 PDT 2013


On 23-09-13 16:16, Dave Crossland wrote:
> On 23 September 2013 15:52, Eric Schrijver <eric at authoritism.net> wrote:
>> How do other Open Source font projects deal with their version numbers? Any
>> best practices?
> semver.org

I’m aware of semver.org—that’s where I picked up the terminology Major, 
Minor, Patchversion.

At the same time, actually following semver is rather difficult because 
I’m not sure its software concepts are easy mappable to fonts:

 1. MAJOR version when you make incompatible API changes,
 2. MINOR version when you add functionality in a backwards-compatible
    manner, and
 3. PATCH version when you make backwards-compatible bug fixes.


*Any* change to a font could be considered an incompatible API change 
(i.e. incompatible with existing designs that use the font).

Of course there are some additions that could be considered to be 
backwards-compatible, like adding extra glyphs… But I think what version 
numbers mean need to be a bit reimagined for fonts.

Like I said, for me it would be more like:
1. MAJOR version constitutes a coherent set of design goals
2. MINOR version constitutes a discrete goal obtained in pursuing these 
design goals
3. PATCH version constitutes incremental progress toward design goals

I can expand on this, of course :)

But what I’m interested in is—what kind of versioning systems are people 
using in the wild?

Are you actually using SEMVER with Google, Dave?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openfontlibrary/attachments/20130923/cb15037c/attachment-0001.html>


More information about the OpenFontLibrary mailing list