Use better version string comparison

[rmsacks]

Currently, this function compares raw version strings such as "7.5.2"
and "9.6" to find the newer version. This worked fine until Tor Browser
version 10 was released and "10.0" is no longer considered larger than
"7.5.2" by this function. This commit changes the function to split the
raw strings on periods and compares the corresponding tuples, such as
(7, 5, 2) and (10, 0). While this does not cover all edge cases, it
should work better for these purposes. It is also simple and avoids
adding an extra dependency compared to other options.

Fixes #498

[vuzdemav]

The pkg_resources.parse_version function in setuptools covers more edge cases in version parsing.

https://setuptools.readthedocs.io/en/latest/pkg_resources.html#parsing-utilities

However, that's not necessarily a reason not to merge this first and then discuss the best long-term choice later.

[rmsacks]

The pkg_resources.parse_version function in setuptools covers more edge cases in version parsing.

I definitely agree that would be the best solution. However, I do not think that package is part of the standard library (at least not in Debian 10), so I personally did not want to add an extra dependency to a project that I am not very familiar with unless it was completely necessary.

[AsciiWolf]

@micahflee Please, consider merging this PR along with #482, then doing a new torbrowser-launcher release. The last one was more than a year ago and is outdated and broken (without patches applied) now.

[eli-schwartz]

I strongly urge you NOT to use pkg_resources.parse_version() as pkg_resources incurs a very steep penalty just for importing it, while all it actually does is return packaging.version.Version() (or if that raises an invalid version exception, fallback to packaging.version.LegacyVersion(). The packaging module is much more lightweight and is the actual thing you're using anyway, and can be trivially utilized in 4 lines of dead simple code.

Anyway I doubt you'll ever need to fully handle every nuance of python allowed version specifiers including prereleases, postreleases, dev versions, epochs, and people's humorous jokes with alphabetic versions.

You only care about the types of versions Tor Browser uses (which quite obviously would always have eventually gotten to "10").

[vuzdemav]

I withdraw my suggestion of pkg_resources.parse_version. This package shouldn't need to handle version numbers with "beta / alpha / pre" text, because it only ever downloads the final "released" version.

[AsciiWolf]

@intrigeri Could you please also merge this PR along with #482? Thanks! :-)

[intrigeri]

@intrigeri Could you please also merge this PR along with #482? Thanks! :-)

I can't: I only can merge PRs about the AppArmor policy.

[DavidPesticcio]

FYI:

https://www.python.org/dev/peps/pep-0386/#distutils

Taken from the link above:

>>> from distutils.version import LooseVersion as V
>>> v1 = V('FunkyVersion')
>>> v2 = V('GroovieVersion')
>>> v1 > v2
False

Version numbering for anarchists and software realists. Implements the standard interface for version number classes as described above. A version number consists of a series of numbers, separated by either periods or strings of letters. When comparing version numbers, the numeric components will be compared numerically, and the alphabetic components lexically. The following are all valid version numbers, in no particular order:

1.5.1
1.5.2b2
161
3.10a
8.02
3.4j
1996.07.12
3.2.pl0
3.1.1.6
2g6
11g
0.960923
2.2beta29
1.13++
5.5.kw
2.0b1pl0

In fact, there is no such thing as an invalid version number under this scheme; the rules for comparison are simple and predictable, but may not always give the results you want (for some definition of "want").

[eli-schwartz]

distutils.version.LooseVersion is a completely bloated waste of time and CPU cycles if you know the version scheme you're trying to parse is rigidly defined as a tuple of integers. Moreover, the CPython developers have chosen to mark distutils as deprecated and it is getting removed from the stdlib, so now is a terrible time to be creating new code depending on it.

If you crave some complex version class to do your work for you, I've pointed out the packaging module which is a dependency, but fairly lightweight. There is no sensible method to handle "dependencies with edge cases" without dependencies. If you care about edge cases, learn to live with dependencies.

[micahflee]

Fixed (a slightly different way) in #526