> Am Mar 12, 2012 um 17:07 schrieb Christophe Leterrier <
[hidden email]>:
>
> > On Mon, Mar 12, 2012 at 21:33, Johannes Schindelin
> > <
[hidden email]> wrote:
> >>
> >> On Mon, 12 Mar 2012, Christophe Leterrier wrote:
> >>
> >>> Currently Fiji updates up to ImageJ 1.46a (11/12/2011) via the Fiji
> >>> updater. However, thanks to Johannes work, it is possible to use a stock
> >>> ImageJ jar and benefit from further IJ modifications, notably fixing the
> >>> subpixel ROI problems (if I understood correctly), inconsistencies
> >>> between intensity profiles lengths and ROI lengths, and expandable macro
> >>> arrays as a user-selectable option rather than a standard function.
> >>>
> >>> I use Fiji with IJ 1.46h (02/28/2011, updated via "Help > Update
> >>> ImageJ") for two weeks now, and I didn't hit any bug yet. Of course I am
> >>> not doing advanced stuff like IJ2 developers do, but as a regular user
> >>> everything is OK. Would it be possible to close the gap between Fiji's
> >>> IJ1 version and current version? Or is there still some serious issue
> >>> stopping IJ1 at 1.46a in Fiji? Can I help in achieving this ?
> >>
> >> Good point, Christophe. So to make this process much more transparent,
> >> let's have a vote here, on this mailing list (please reply-to-all to keep
> >> the transparency of the process alive):
> >>
> >> A) update ij.jar whenever there is a new daily build available in
> >>
http://fiji.sc/imagej.git> >>
> >> B) update ij.jar with each and every intermediate release (i.e. versions
> >> like 1.46i, but not 1.46i11)
> >>
> >> C) update ij.jar only after extensive, manual testing (due to the work
> >> involved, this cannot be done with each intermediate release)
> >>
> >> D) update ij.jar only with major releases (i.e. 1.47, but not 1.47b)
> >>
> >> E) do not update ij.jar at all but let users pick their preferred version
> >> via Help>Update ImageJ
> >>
> >> So far, I chose option C) but obviously that is not good enough for users.
> >
> > I guess E) would be OK, but the IJ updater only allow to downgrade
> > from the last minor version (1.46h as of today) to previous major
> > versions (1.43, 1.44, 1.45...). So if encountering a show stopper, it
> > is difficult to downgrade to the last good minor version rather than
> > going all the way back to the previous major version. In fact I have
> > no idea where to find 1.46a to 1.46g, I couldn't find them on IJ's
> > website. I guess one good thing would be for Wayne to modify the IJ
> > updater in order to propose the last previous minor revision (i.e.
> > 1.46g as of now) as a choice in the drop-down menu?
> >
> > So in the end I'd prefer option B), mostly because it is what I do now
> > (always updating IJ in Fiji to the latest minor version). As most user
> > would follow this default update path, detecting potential problems
> > would be fast. Hopefully, as you said, this would be a temporary
> > arrangement, waiting for IJ2 to be shipped.
> >
> >> Please note also that this is only an issue as long as we haven't switched
> >> to ImageJ2 (which is coming along nicely), as ij.jar will move to ImageJ's
> >> update site then along with all the other IJ2 .jar files.
>
> I also think B) would be a reasonable choice!
So this is what I implemented yesterday. Please note that the Jenkins job
uploads the new ImageJ1 without any testing... If things break you can
Locked
