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

[Stephan Saalfeld]

Hi Johannes and Curtis,

thanks for explaining.  I am not familiar with the differences between
snapshots and releases.  I trust in you to make the right choice.

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.

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.

Be patient with me---I have to finish my thesis by July 31---no further
mercy.  Back in hacking mood after that...

Cheers,
Stephan




On Sat, 2012-07-07 at 15:00 -0500, Johannes Schindelin wrote: 
> Hi Curtis,
> 
> [Re-Cc:ing everybody stripped by scijava. I love when GoogleGroups does
> that. It is really helpful.]
> 
> On Sat, 7 Jul 2012, Curtis Rueden wrote:
> 
> > I will reply in more detail on Monday, but we should consider using a new
> > release version number (e.g. 20120707) instead of using a snapshot.
> 
> Fair enough!
> 
> > Otherwise I will have to make a new release version anyway when we release
> > beta3 next week.
> 
> I did not think of that. But is mpicbg really needed for ImgLib2? A quick
> "git grep mpicbg\\. imglib2/" reveals that there are only references in
> algorithms-gpl, broken, ij, scripting and tests (and a link that is
> probably incorrect in PolygonRegionOfInterestTest in core).
> 
> > Do you want to start versioning mpicbg in sync with imglib2? (Maybe we
> > should see what Stephan wants there).
> 
> Yep, would be good to hear from Stephan about his plans there.
> 
> Ciao,
> Johannes
>