Comment 6 for bug 629727

The jumping straight up to a number that is about two-thirds is purely for intuitiveness of users and to give a proportionate demonstration of our believe in the overall status (eg. political rather than technical). Whether or not it was a good thing is do is somewhat by-the-by.

I've had discussions with Colin Watson (who often has clear insight in such matters) and Keith Packard (FontConfig). One issue (as noted by Mark) is that the software versioning that we're used―and which is documented in great detail in the Debian Policy Manual:

  http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

"goes up to eleven" per component. The version numbers are not purely a strict concatenation of the digits, with each component being compared based on its own numerical merit. If one needs more than nine-revisions then you go to ten, eleven, twelve and these are evaluated as being numerically higher:

  ...x.1.y... < ...x.9.y... < ...x.10.y...

despite ten and one both beginning with a '1' and nine with a '9'.

Colin's thoughts leaned towards using a strict, subset for encoding the preferred version into the available fractional codespace and *documenting* this in the developer readme such that there are bounds (effectively, we agree not to go above nine, and any increase requires a bump of the next digit up) ...and that Canonical agree to bump the minor (.6) as the next decimal is exhausted. This gives ~33 releases until next summer and retagging as 1.000; There is a third digit if we really get desperate: ~338.

Keith noted that the 32-bit (16+16-bit) version is treated as a simple comparison, and only in the case of a collision is the comparison any use (this is at odds with non-Linux operating systems, which appear to be using the string version). His suggestion was for an 8.8.8.8 encoding across the bits, the actual /encoding/ being somewhat arbitrary―and as we have noted, it already varies between implementations. He further stressed that that the packaging system takes care of removing those version conflicts in the first place by other having the latest packaged version installed. The disadvantage is that applications are already setup to do a 1/65,535 encoding for the fraction.

I (still) don't yet have a clear answer distilled in my head, but yes David, I concur with you that version C is possibly the least-worst of a bad bunch, given the options and a desire to validate against whatever piece of software it is on your side that is complaining.

Given a free choice (B) might be my preferred desire; the textually formatted version number (suitably restricted as Colin suggested, to numerical values 0-9 per component) is there in its original simple glory, and is what the user sees; and the binary /encoding/ (transformation) of this stored in the 'head' also fulfils the criteria of monotonically incrementing. An encoding that was only capable of perpetually inserting 0.6, or 0.7, or 0.8 into the binary field would fail the criteria to monotonically increment.

(We can add some regression testing code to validate that the binary head->fontRevision is indeed incrementing).