Support "1.00.1" as a semver

[drnic]

I don't know why they put 00 in their versions :/

In ftp://ftp.freetds.org/pub/freetds/stable/ there are lots of ftp://ftp.freetds.org/pub/freetds/stable/freetds-1.00.1.tar.gz where the version is 1.00... and your semver checking doesn't like it.

...
  File "/opt/resource/check", line 217, in _versions_to_output
    versions.sort(key=lambda x: semver.parse_version_info(x[self.version_key]))
  File "/opt/resource/check", line 217, in <lambda>
    versions.sort(key=lambda x: semver.parse_version_info(x[self.version_key]))
  File "/usr/local/lib/python3.6/site-packages/semver.py", line 131, in parse_version_info
    parts = parse(version)
  File "/usr/local/lib/python3.6/site-packages/semver.py", line 52, in parse
    raise ValueError('%s is not valid SemVer string' % version)
ValueError: 1.00.1 is not valid SemVer string

Could we allow the test to be more flexible?

[aequitas]

I'm relying on the semver package to parse versions so they will be reliably sorted (https://github.com/aequitas/concourse-ftp-resource/blob/master/assets/ftp.py#L141). So I'm currently bound by what they support (https://github.com/k-bx/python-semver). Supporting anything beyond that would mean implementing and testing various edge cases in all kind of version notation. Like in your case, you would get problems like which version would come first: 1.00.1 or 1.0.1?

I'm not really keen on solving this problem myself right now. But if you want to give it a try I would gladly accept a generic solution. Like adding a parameter to specify different well defined/custom versioning schemes, with semver being the default for backwards compatibility.