We build compatibility versions as
where the build ID's by default are a numeric representation of the date that
the build happened.
Previously we attempted to mangle this into a valid toolkit version by
<appversion>.<appbuildid>.<platformbuildid> if the build IDs
were the expected length. We also split each build ID into two version parts
since the version comparator couldn't handle their full size.
This mangling fails when comparing a major version with a new patch version:
<majorversion>.<appbuildid>.<platformbuildid> gets compared to
<majorversion>.1.<appbuildid>.<platformbuildid>. Unless that patch version
(1 here) was greater than the build ID (currently in the tens of millions) the
patch release would appear to be older than the previous version.
This changes this so rather than attempting to mangle the entire string into a
single toolkit version we split out the string into their components.
First we compare the app versions using the version comparator which is
definitely the correct thing to do.
For the build IDs we check if they are entirely numeric (which is the case for
the date based default) and if so just compare them numerically.
We assume that if the IDs aren't numeric then they are something defined by a
custom build of Firefox, we can't know what form that takes so I've chosen to
fallback to just using the version comparator since it will handle things such
"build1" < "build10" and it should be straightforward for anything more
complex to choose a form that works.