The Truetype specifcation has version numbers in two main places:

  1. 'name' table, entry nameID=5, string, in the form "^Version [0-9]{1,5}\.[0-9]{1,5}([^0-9].*)?$"
  2. 'head' table, fixed point fraction 16-bits.16-bits

Both locations allow any version number in the range 0-65,535 point 0-65,535.  With the string name being a free-form string beyond that.  The example given by MS in the OpenType specification for the field is:

  "Version 1.00 June 1, 1990, initial release"
  http://www.microsoft.com/typography/otspec/name.htm

Which demonstrates the intent that strings be longer than a simple Major.Minor.  Running the following test over the fonts already on my current system:

  dpkg -S .ttf | cut -d\  -f2 | xargs strings | grep Version | grep [0-9]\\.[0-9]*\\.[0-9]* | sort | uniq

shows several version numbers that are compliant with the Truetype specification and which are similar or identical to the intended format proposed and introduced at the top of this bug report (Major.Minor.Sub.Increment)

 Version 0.730.4 2008
 Version 2.4.3
 Version 2.4.4

The question is therefore /not/ how or if to set the Version field (eg. "Version 0.6.7", or "Version 0.6.7.1" for a re-spin), but /what/ to do about aligning this comparatively verbose field with the fixed-point fraction provided in the 'head' table.  Currently Microsoft general operating system and utilities appear to use the Version string.  Apple's documentation for the fixed-point fontRevision merely states "set by font manufacturer", so it's entirely possible that the fraction could be /anything arbitrary/.  Currently the fractional component has been set to by Font Lab to 0xab85 (~0.6700 decimal).

Microsoft hints at (their apparent understanding of) obsoleteness for the binary fraction from the 'head':

  http://www.microsoft.com/typography/otspec/head.htm
  "For historical reasons, the fontRevision value contained in this table is not used by Windows to determine the version of a font. Instead, Windows evaluates the version string (id 5) in the 'name' table. "

FontConfig (the matching and substitution system used on Linux and Ubuntu) appears to cache the value of the fractional from the head, but doesn't parse it, merely evaluating that it is not equal to zero (ie. not set/not present) and ignoring it if it is:

  head->Font_Revision != 0 // value cached (but not parsed) is non-zero
  TT_NAME_ID_VERSION_STRING // not evaluated
  TT_NAME_ID_UNIQUE_ID // commented out, not evaluated

Testing: setting the Version (nameid=5) and Unique ID (nameid=3) string to contain "0.6.7" (or even "0.6.7.1") both work fine and the implementation in FontForge picks a fractional representation of 0xaaaa when offered '0.67' (as compared to 0xab85), which probably illustrates the arbitrariness of the field.

Mark: your call.  The numbering scheme (documented in the other shared document and, I believe, codified here) will only be present in the Version and Unique ID (string field), with something simpler in the binary form.  Dalton Maag's concerns are that these should be interchangable... ie. about not putting more verbose data in the Version string (nameid=5) that can be included in the fractional head->fontRevision?  (noting that the ->fontRevision encoding varies between implementation).