[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