I agree, reproducible analysis is extremely important. It would be nice to have numbered Fiji releases that can be referred back to (and even better, rolled back to) at a later date. i.e. something like:- http://rsbweb.nih.gov/ij/download/src/ http://developer.imagej.net/downloads but via the updater, and with all dependencies frozen.
Not sure how painful that would be to implement, but so long as you don't need to cache too many versions and their dependencies I guess it shouldn't be unbearable. A lot of people seem to get annoyed by the constant update requests, so it would also be nice to have the option to update only to such numbered releases as they come out (one a week / month / quarter?) In the meantime, the obvious workaround to ensure some important analysis can be reproduced at a later date is to turn off the updater and archive the whole Fiji / ImageJ app. At ~200M zipped for Fiji that's not ideal. I usually advise co-workers *not* to update Fiji / ImageJ when they are in the middle of some important analysis task because updates can be a double-edged sword. Regards, Graeme PS. I realise this is not a Fiji list, but since Fiji / IJ2 use the same updater I figured it's not too far off-topic On Sat, Aug 17, 2013 at 11:16 AM, Michael Doube <mich...@doube.net> wrote: > Hi everyone, > > One of the things which has bugged me for a while about Fiji in > particular and which might affect IJ2 is that it is quite hard to define > the state of the program when you have to describe it in a scientific > paper, because there aren't atomic versions easily accessible to users, > which encapsulate the entire state of the IJ system. > > You could, I suppose, go to Help > ImageJ and get the IJ and Java > versions, and then go to Help > About plugins and get some information. > But, that relies on plugin authors including a method containing that > info, which they often don't do. > > Further, what happens when libraries are changing in the back end, which > don't relate to those version numbers, but which those plugins might > use? Or when they use methods from other classes unbeknown to the user? > > In other words, if you want to repeat the experiment, how do you restore > the conditions and get the code configuration back? Is copying the whole > Fiji.app directory the only way? > > I am imagining a Git-like hash which relates to a unique configuration > and which anyone can reproduce by entering the same hash - like checking > out a commit, you would check out a config. > > Michael > > _______________________________________________ > ImageJ-devel mailing list > ImageJ-devel@imagej.net > http://imagej.net/mailman/listinfo/imagej-devel _______________________________________________ ImageJ-devel mailing list ImageJ-devel@imagej.net http://imagej.net/mailman/listinfo/imagej-devel
