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 < [email protected]> 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 >
_______________________________________________ ImageJ-devel mailing list [email protected] http://imagej.net/mailman/listinfo/imagej-devel
