Closed yarikoptic closed 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.
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
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.
ok, so I will assume that pure 'date' release versioning is to stay and will update debian package away from '0.date'
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
date
versioning . pros: simple, cons: would nohow be able to depict breaking compatibility etcPlease advise ;)
Thank you very much in advance