[ImageJ-devel] [fiji-devel] Re: Permission to bump mpicbg.version to 2.0.0-SNAPSHOT?

[Curtis Rueden]

Hi all,


> Basically, the problem with snapshot versions is that they are moving
> targets. So imglib2-2.0.0-beta3 cannot depend on mpicbg-2.0.0-SNAPSHOT.
> That was my thinko and Curtis corrected that.


Yes, the good thing about release versions (i.e., any version without
"-SNAPSHOT" as the suffix) is that they never change after deployment
(i.e., once they are available to anyone external). The idea is that adding
a release version dependency creates a looser-and-more-stable linkage
between projects, whereas a snapshot dependency creates a
tighter-but-less-stable one.

The way we are doing it with ImageJ2 and ImgLib2 is that the development
version of ImageJ2 depends on an ImgLib2 snapshot. When we do a release, we
do a release for the entire stack, with both ImageJ2 and ImgLib2 versioned
the same (but if you want to change this in the future, we can discuss).

It is forbidden for a release version of a project to have any snapshot
dependencies (because then depending on that release would not be
transitively stable). Therefore, when we do a release of the ImgLib2
projects, we need a new-enough release version of mpicbg as well—at least
until the transition away from mpicbg is complete someday.


> Okay, that would be version 20120621, then, as that is the date of the
> commit in fiji.git, referring to the mpicbg commit 4200032831.
>


I verified that the Updater considers my compiled version of that revision
> and what you uploaded as identical, so I "deployed" (== "uploaded to the
> Maven repository" in Maven speak) the latter[*1*].


Sounds perfect!

Regards,
Curtis


On Sun, Jul 8, 2012 at 2:50 PM, Johannes Schindelin <
Johannes.Schindelin at gmx.de> wrote:

> Hi Stephan,
>
> On Sun, 8 Jul 2012, Stephan Saalfeld wrote:
>
> > thanks for explaining.  I am not familiar with the differences between
> > snapshots and releases.  I trust in you to make the right choice.
>
> Basically, the problem with snapshot versions is that they are moving
> targets. So imglib2-2.0.0-beta3 cannot depend on mpicbg-2.0.0-SNAPSHOT.
> That was my thinko and Curtis corrected that.
>
> > To explain the mpicbg situation: I consider the version of the git
> > repository that is committed as submodule to the fiji repository the
> > stable release because I tested it in the full Fiji context (at least
> > for compiling issues) which includes TrakEM2 and ImgLib1/2.  That
> > version corresponds to what is uploaded to the Fiji updater.
>
> Okay, that would be version 20120621, then, as that is the date of the
> commit in fiji.git, referring to the mpicbg commit 4200032831.
>
> I verified that the Updater considers my compiled version of that revision
> and what you uploaded as identical, so I "deployed" (== "uploaded to the
> Maven repository" in Maven speak) the latter[*1*].
>
> > The dependencies in imglib2 are wrong transformed comments.  imglib2-ij,
> > imglib2-algorithms-gpl, imglib-scripting and imglib2-tests use utility
> > classes that I will transfer to imglib2 in August now that I've seen it.
> > imglib2-algorithms-gpl and imglib-scripting use it for transformation
> > which can now be replaced by imglib2-realtransform (actually the
> > transform as implemented there is obsolete now that RealViews exist).
> >
> > My plan is to free imglib2 from mpicbg dependencies because it will
> > incorporate all its functions wrapped in improved interfaces.  This,
> > however, is a longer term project which means that mpicbg will remain
> > for quite some time, mainly in the Fiji context for TrakEM2 and other
> > plugins.  Synchronizing version numbers between imglib2 and mpicbg would
> > thus be misleading in my understanding.
>
> Okay, great, thanks for the clarification! Much appreciated.
>
> > Be patient with me---I have to finish my thesis by July 31---no further
> > mercy.  Back in hacking mood after that...
>
> Yep, the thesis is more important right now. Good luck with that!
>
> Ciao,
> Dscho
>
> [Footnote *1*] I did not upload my compiled version, since -- as you know
> -- .jar files are really .zip files, storing timestamps with the files, so
> by necessity the .jar files are different when they are recompiled. The
> Updater is a bit clever about that situation and inspects the .zip
> contents (in newer incarnations, it ignores even more things that depend
> on the build environment/date).
>
> --
> Please avoid top-posting, and please make sure to reply-to-all!
>
> Mailing list web interface: http://groups.google.com/group/fiji-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20120709/786b4795/attachment.html>