Centralize FreeSurfer version parsing

[effigies]

This change replaces interfaces.freesurfer.preprocess.FSVersion with interfaces.freesurfer.Info.looseversion(), and makes the corresponding updates throughout the code.

The goal is to get a well-behaved version string that is comparable across versions, including no installation. LooseVersion is used in anticipation of the most common use case.

FSCommand().version is updated to pull the version string out of Info.looseversion() to ensure that the same logic is applied whenever a parsed version string is used.

Release versions use simple version strings (no githash). Post-v6 dev versions follow format suggested by @satra in #1928: 6.0.0-dev.GITHASH. dev versions without githashes are parsed as before.

Closes #1928.

[satra]

@effigies - thanks for this. but i need to bring up one issue with my suggestion.

In [11]: LooseVersion('6.0.0') > LooseVersion('6.0.0-rc1')
Out[11]: False

In [12]: LooseVersion('6.0.0') > LooseVersion('6.0.0-dev.g123456')
Out[12]: False

the first case often predates the release, while the second case post-dates the release. also github hashes are not comparable, which is why git describe looks like this 6.0.0-1234-g123456 the middle number ensures comparison except for comparing across branches.

i really don't know a good solution to this that goes across the software we support. we may have to do this on a case by case basis.

[satra]

unless we do it like nipype dev version == 0.13.0-gcf2d093.dev (we should fix that as well :) ), where after release we bump the dev version to the next release.

[effigies]

Agreed that -dev and -rc1 play havoc with LooseVersion, but I think our checks will be >= LooseVersion('6.0.0') or similar almost all the time. We could run up against a situation where somebody's running a release candidate after we make a branch dependent on the stable release, but then the fix is "run stable".

I'm also not super worried about ordering of dev releases based on githashes, but they do actually solve this problem by using YYYYMMDD-GITHASH, so we could do that. e.g. 6.0.0-dev-YYYMMDD-GITHASH. It's kind of moot unless/until we're make a logical branch on "newer than this specific dev version", but there's no reason not to allow for that eventuality.

[codecov-io]

Codecov Report

Merging #1958 into master will decrease coverage by <.01%.
The diff coverage is 65.51%.

@@            Coverage Diff             @@
##           master    #1958      +/-   ##
==========================================
- Coverage   72.49%   72.49%   -0.01%     
==========================================
  Files        1065     1065              
  Lines       54268    54282      +14     
  Branches     7836     7838       +2     
==========================================
+ Hits        39343    39350       +7     
- Misses      13702    13710       +8     
+ Partials     1223     1222       -1

Flag	Coverage Δ
#smoketests	72.49% <65.51%> (-0.01%)	⬇️
#unittests	70.03% <44.82%> (-0.01%)	⬇️

Impacted Files	Coverage Δ
nipype/interfaces/freesurfer/preprocess.py	66.7% <100%> (-0.08%)	⬇️
...ype/interfaces/freesurfer/tests/test_preprocess.py	89.04% <50%> (ø)	⬆️
nipype/interfaces/freesurfer/base.py	66.91% <62.5%> (+0.25%)	⬆️
nipype/interfaces/base.py	84.66% <0%> (-0.19%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 378e295...a6b5b7d. Read the comment docs.