The Fiji Updater was developed in a constrained time frame: the Google Summer of Code. After some discussion with the student, the mentor (and me) agreed to leave downgrading completely out of the scope of the Fiji Updater. It was just too hard to implement (dependencies are really tricky then).

Further, the problem with stable updates is more social than technical.

Sure, we could include another tag in the db.xml.gz file, say, <experimental-version> with attributes checksum, timestamp and filesize, and live inside the <version> tag. That is not so much a problem.

The problem is more to guarantee a consistency between the different maintainers' ideas of what means "stable".

On the other hand, if you would like to have something like the bleeding edge that is provided by the "daily build" of ImageJ, you might want to have a look at the WebStart'able Fiji versions: http://pacific.mpi-cbg.de/webstart/Fiji.jnlp and http://pacific.mpi-cbg.de/webstart/Fiji-stable.jnlp.

The stable version there is exactly the same as you would get via the updater (but it is only updated once per each night), while the unstable version is made from the output of the nightly build (if it succeeds, that is).

I agree that deciding what is "stable" is a social challenge. And I think the ability to downgrade is outside the scope of this ticket as well.

I guess the question is whether this type of feature is something we want to do in the future at all. If so, we can leave this ticket sitting around for now; otherwise, we can close with "WONTFIX."

Okay, let's use this forum to enumerate the issues that need to be solved in order to support stable vs experimental updates.

The main complication is that two different plugins could depend on the same library (say, fiji-lib.jar), but at different versions. For the bleeding edge, we try to make sure that everything works okay, but it is very hard to impossible to guarantee the same for multiple versions per plugin.

Another complication is to record the user's wish. Re-using the ij.Prefs method does not work, because that is local per computer, not per Fiji installation.

Also, something that might be fixed in an "unstable" component will waste the time of the maintainer until she finds out that it is broken only in the "stable" version. The other way round, it will be much harder to identify regressions when too many users stay with obsolete but stable components. (For Fiji -- which is meant to be a research platform -- I think we can afford to stay on the slightly unstabler side, especially given our typical response time.)

For the moment, I can only think of one other issue: it is much harder to reproduce failing setups when the user can choose between different versions for all of Fiji's components. It is hard enough with users who choose to stay behind (out of fear that something that works will break after an update). Believe me, I fight with that every day.

(In reply to comment #3)
> The main complication is that two different plugins could depend on the same
> library (say, fiji-lib.jar), but at different versions. For the bleeding edge,
> we try to make sure that everything works okay, but it is very hard to
> impossible to guarantee the same for multiple versions per plugin.

Could we disallow mixing and matching of libraries, then? So Fiji would run in either "latest" mode, or in "stable" mode, as far as updates are concerned. This would reduce the interplay between incompatible library versions.

> Another complication is to record the user's wish. Re-using the ij.Prefs method
> does not work, because that is local per computer, not per Fiji installation.

I think ij.Prefs is local per user—at least on Mac OS X, it stores the IJ_Prefs.txt file in ~/Library/Preferences.

> Also, something that might be fixed in an "unstable" component will waste the
> time of the maintainer until she finds out that it is broken only in the
> "stable" version. The other way round, it will be much harder to identify
> regressions when too many users stay with obsolete but stable components. (For
> Fiji -- which is meant to be a research platform -- I think we can afford to
> stay on the slightly unstabler side, especially given our typical response
> time.)

We have this problem with Bio-Formats, but you can generally tell from the stack trace line numbers which don't match. The first question we have to ask everyone is "have you tried with the latest version?" But I think you have to ask that question regardless, in case the user hasn't run Fiji updates recently.

> For the moment, I can only think of one other issue: it is much harder to
> reproduce failing setups when the user can choose between different versions
> for all of Fiji's components.

I was thinking users would need to choose either stable mode or latest mode, and not mix and match.

> It is hard enough with users who choose to stay
> behind (out of fear that something that works will break after an update).
> Believe me, I fight with that every day.

Many of the "fearful" users might use the stable update mode, rather than completely avoiding updates as they do now, which would at least be a step forward.

All of that said, I want to clarify that I filed this ticket because it was on my to-do list as an action item resulting from our prior conversation, rather than due to any acute need. I think a stable update mode could be useful but as you point out there are pros and cons, and it certainly adds maintenance complexity.

I'll mark this as "Later", because I still have no good idea how to solve the conundrum.