[ImageJ-devel] (no subject)

Johannes Schindelin schindelin at wisc.edu
Thu May 16 11:25:38 CDT 2013


Hi Curtis,

On Thu, 16 May 2013, Curtis Rueden wrote:

> > In particular, I am worried about these four lines:
> >
> > Warning: obsolete 'jars/lwf-stubs-4.5-SNAPSHOT.jar' still installed!
> > Warning: obsolete 'jars/loci-legacy-4.5-SNAPSHOT.jar' still installed!
> > Warning: obsolete 'jars/scifio-devel-4.5-SNAPSHOT.jar' still installed!
> > Warning: obsolete 'jars/turbojpeg-4.5-SNAPSHOT.jar' still installed!
> 
> Yes, and these lines would also break things:
> 
> > Would upload new version of jars/jai_imageio-4.5-SNAPSHOT.jar
> > Would upload new version of jars/ome-xml-4.5-SNAPSHOT.jar
> > Would upload new version of jars/scifio-4.5-SNAPSHOT.jar
> > Would mark jars/loci-common-4.4.9-SNAPSHOT.jar obsolete

Bummer.

> > P.S.: I will now test whether the uploader still works if I copy over
> > only jars/*updater*.jar to Fiji; this would allow us to punt on
> > Bio-Formats for now and do a full upload later, at a more opportune
> > time.
> 
> OK, that may be the best plan for now. We will have to resolve this within
> the next two weeks anyway for the ImageJ 2.0.0-beta-7 release. My current
> thinking is that we can ship Bio-Formats 4.4.x stable releases (used by the
> "LOCI plugins") in parallel to SCIFIO development releases (used by
> ImgLib2/ImageJ2/etc.), because they have different package structures. We
> will just need to strip out the loci.* packages from the SCIFIO development
> releases first, which should be easy enough.
> 
> Another thing we could do to assist with this sort of thing is to set up a
> test update site for ImageJ, and one for Fiji. Then we can verify behavior
> in a safe environment before uploading to the real update sites.

The problem with all of this is that both you and me are not exactly in
dear need of yet more tasks.

So I would like to suggest humbly that we should just switch back things
to the bleeding edge as we used to? Do not get me wrong, I would love to
have stable versions, but history taught us that that's not what our users
need. And if we can somehow support our users better while having a
lighter maintenance burden, what could be wrong with that?

Ciao,
Dscho



More information about the ImageJ-devel mailing list