Make formatVersion in metainfo.plist a major/minor

[typesupply]

We have switched to an incremental approach to updating the spec rather than holding lots of changes until a major version bump. To make it easier for readers to more easily identify these new format UFOs we need to make the formatVersion in metainfo.plist a float instead of an int.

[justvanrossum]

Suggest to only ever to increment by 0.1, and not go over 3.9. After that 4.0 is inevitable and then we should change the format specifier in metainfo.plist.

[anthrotype]

What about, instead of changing the type of the existing formatVersion element from int to float (which would break existing implementation), we add an additional int element <formatVersionMinor> which defines the minor version, and the existing <formatVersion> continues to define (implicitly) the major version?
This way existing clients will (with all probability) ignore the extra element (unless they are overly strict in their validation), while updated clients will be able to read the new formatVersionMinor element and act accordingly.

We could settle on a versioning policy whereby we only ever change the major version when: 1) we remove support for existing pieces of data; or 2) change their semantics in a breaking way. Whereas we would bump the minor version every time we add extra elements or attributes to existing elements or define new public. lib keys or add whole new files to the UFO package.

[anthrotype]

(maybe formatMinorVersion reads better in English than formatVersionMinor)

[anthrotype]

Alternatively, we would be forced to bump the formatVersion directly to 4.0, that is bump the major version because we changed the type of formatVersion element itself from int to float.

[typesupply]

I like the formatVersionMinor idea. We have a versionMinor field in fontinfo.plist so I'm fine with the awkward order.

[benkiel]

+1

[anthrotype]

OK, I'll work on fontTools.ufoLib support for parsing a new optional formatVersionMinor element in metainfo.plist.
But what about the GLIF format attribute? Do we want to add a new optional formatMinor attribute? Or do we re-purpose the existing format attribute to be a dot-separated "minor.major" string?
XML attributes (unlike plist) do not have an intrinsic type, they're just strings.
I am leaning towards simply doing format="2.1", instead of adding new formatMinor for GLIF.

WDYT?

[benkiel]

That sounds like the simplest thing

[anthrotype]

Hm. However the whole point of defining an additional minor version was to avoid breaking existing tools, since the new features are meant to be additive. If we change the meaning of GLIF format attribute from an integer to a dotted version string, then existing tool will break (e.g. you won't be able to read a UFO 3.1 with GLIF 2.1 in an editor that only supports up to UFO3/GLIF2).
Older versions of fontTools.ufoLib, to take one, will refuse to load such GLIF 2.1 with "Unsupported format version" because it casts to int() and check if it's in (1, 2).

[anthrotype]

cc @justvanrossum

[benkiel]

@anthrotype You've just argued against your earlier lean; but this raises a really good point. Based on that, I would think the thing to do is to also add formatMinor to GLIF, keeping format for the major format. Nothing will break then.