Decide what to do about `v` prefix in software versions
michellewang opened this issue · comments
Continuing the conversation from #196 with @nikhil153.
I have a preference for not having the v prefix in front of the pipeline version numbers because I don't think it's very useful/informative and it's one extra letter to type when navigating directories. Right now the (soon-to-be legacy) code base has a mix of with/without that prefix (runscripts don't have it, extractors do) because Tractoflow derivatives break if files are renamed since they use symlinks with absolute paths. In the refactored code base currently I don't add the v prefix (though that would be an easy change).
However, the Tractoflow thing is a wider problem that should be fixed regardless of the presence of the v prefix, since the absolute symlinks make it very difficult to move the files anywhere else, which is definitely not ideal. The current Tractoflow runscript replaces all the absolute symlinks by the files they point to, so we shouldn't get this problem anymore, but for datasets that were previously processed (e.g. QPN) we should write a utility script to crawl through derivatives/tractoflow/ and do the same replacement. Once that is done we will be free to decide whatever we want about the v prefix :)
Regarding the BIDS docs "recommendation": I read that as saying that <variant> can be anything, I am not sure if they genuinely have a preference for e.g. fmriprep-v1.4.1 vs fmriprep-1.4.1.
Yeah I would not read too much into the bids spec for something like this.
Maybe one possibility would be to: use the version name the software / pipeline uses.
I have seen / maintained software that, for some reason, have vX.Y.Z and others have X.Y.Z.