On 23-09-13 16:16, Dave Crossland wrote:
On 23 September 2013 15:52, Eric Schrijver <e...@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?
