search

rordenlab / dcm2niix

dcm2nii DICOM to NIfTI converter: compiled versions available from NITRC
https://www.nitrc.org/plugins/mwiki/index.php/dcm2nii:MainPage
Other
886 stars 228 forks source link

could you please tag (annotated tags are the best) releases #28

Closed yarikoptic closed 8 years ago

yarikoptic commented 8 years ago

Thank you very much in advance

neurolabusc commented 8 years ago

I used the commands git tag -a 20160606 -m "release 06June2016 (adds BIDS support)" git push origin 20160606 to generate a new annotated release. Please check this is what you want.

yarikoptic commented 8 years ago

If you decide to go with versions solely based on the date -- then sure, it is all perfect. Just note that now you would not be able to switch to some other versioning scheme unless you release number would be greater than 20160606. So, if I were you, I would have made it e.g. 0.20160606 or 1.20160606 so you could at some point signal the importance of the release (e.g. backward incompatibility) by beefing up leading version number

neurolabusc commented 8 years ago

Understood. I actually do not see this software changing much in the future. It is an efficient but minimal converter from DICOM to NIfTI. I envision the primary reason for new versions will be vendors coming up with new interpretations of the DICOM standard.

yarikoptic commented 8 years ago

ok, so I will assume that pure 'date' release versioning is to stay and will update debian package away from '0.date'

yarikoptic commented 7 years ago

Great to see dcm2niix leaping forward despite original assessment of becoming stale ;) But there is a minor catch -- inconsistency. Original versions (20160606, ...) followed pure date format (which I adopted for NeuroDebian) and new ones (e.g. 1.0.20161101) follow 1.0.date. Since 20160921 is way bigger than 1, if we adopt new versioning scheme as is -- noone would get their neurodebian packages of dcm2niix upgraded. Two possible workarounds

  1. revert back to pure date versioning . pros: simple, cons: would nohow be able to depict breaking compatibility etc
  2. us (and now official maintainer of dcm2niix in Debian Ghislain) working around by introducing an epoch to the debian version of the package (e.g. 1:1.0.20161101) making it to sort after any non-epoched version.

Please advise ;)