Some further thoughts on the uses of and motives behind the new versioning system:

AFNI has always been maintained continually -- i.e., new programs and options are added as applications and ideas arise, and any bugs are fixed ASAP when discovered. As a result, updates have been added and built frequently, sometimes weekly -- often these are very minor changes, and major ones are often noted directly on the Message Board. Importantly, none of these aspects of our “build often” approach will change with the implementation of the new versioning system. And as always, the version number that you are currently using can be discovered by typing the command ‘afni –ver'.

There are several impetuses for enumerating “major.minor.micro” (or roughly, “yearly.quarterly.oftenly”) updates:

1. to increase reproducibility and accounting in published work (e.g., the new @get.afni.version script enables fetching the source code tree for a particular AFNI version number, if someone wishes to duplicate the processing as precisely as practicable);
2. to facilitate and clarify discussions on the Message Board;
3. to keep track of updates in the code (new programs, new options, updated defaults, bug fixes, etc.);
4. to make it easier to maintain a consistent pipeline through the course of a project (e.g., if an unwanted update occurs juuuust as one is writing up a long study);
5. to encourage users to keep their code versions as up-to-date as possible (if your AFNI is from a year ago, it's well past time to take 5 seconds and run “@update.afni.binaries -d” -- update early, and update often!).

In terms of #5, by default a gentle suggestion to update one's AFNI will be shown when the system's version is two quarters (or, perish the thought, even more) out of date. For those who like to throw caution to the wind, this can be turned off by setting the following environment variable in your ~/.afnirc file (or similarly in a ~/.bashrc, ~/.cshrc, etc. file):
AFNI_VERSION_CHECK = NO

It is conceivable that some users may be worried by seeing the version numbers ticking upward, wondering if they should: A) update and risk losing their beautiful results, or B) stay the course and risk being hammered by a reviewer who won't allow even one micro-build to go by unused. Again, most micro-updates will be just that -- very small, such as adding new program options. Major bug fixes or re-tacking of our philosophical sails will still be announced on the Message Board.

Additionally, users should be aware that a detailed log of code updates is maintained and available online here:
[afni.nimh.nih.gov]
whence you can follow the various levels of alterations to the code; e.g., in all its enthralling detail (dating back to 1996) and by the afni_history report :
[afni.nimh.nih.gov]

And, if you dare, you can always ask the advice of the nearest AFNI coder near you, since each is only a Message Board post, or email, or cronut-bribe away.


As a concluding note on versioning:
"Always be a first-rate version of yourself, instead of a second-rate version of somebody else." -- Judy Garland

.



Edited 1 time(s). Last edit at 01/06/2016 09:54PM by Daniel Glen.