[ImageJ-devel] Breaking API changes and BOM version bumps

[Tobias Pietzsch]

Hi Mark,

imglib2-tests and
imglib2-algorithm-gpl
are fixed already.

I’ll check BDV and TrackMate tommorrow.

all the best,
Tobias

On 17 Mar 2015, at 00:03, Mark Hiner <hiner at wisc.edu> wrote:

> >Next pizza & beer are on me.
> 
> You should rename packages more often! :)
> 
> Neither of you should be hard on yourselves - our release history is filled with mistakes like this, and worse. Until dependency convergence is automatically tied to the release process, there will be more.
> 
> >If you could point me to packages that are hit by the imglib-algorithm change
> 
> Potentially affected components that I know of:
> BDV-core
> TrackMate
> imglib2-tests
> imglib2-algorithm-gpl
> 
> I really do have to fix ij1-patcher before uploading anyway, and just adding back the moved classes would be minimal effort. So the situation is far from dire.
> 
> Best,
> Mark
> 
> On Mon, Mar 16, 2015 at 4:43 PM, Tobias Pietzsch <pietzsch at mpi-cbg.de> wrote:
> Hmm, actually I think I’m to blame in this case because I did the release without properly thinking about the version numbers.
> If you could point me to packages that are hit by the imglib-algorithm change, I’ll try to fix them.
> best regards,
> Tobias
> 
> On 16 Mar 2015, at 21:58, <tinevez at pasteur.fr> <tinevez at pasteur.fr> wrote:
> 
>> Fudge fudge fudge I did this.
>> I am really sorry this is something I vastly overlooked. 
>> Next pizza & beer are on me.
>> 
>> De : Mark Hiner
>> Envoyé : ‎lundi‎ ‎16‎ ‎mars‎ ‎2015 ‎20‎:‎38
>> À : Tobias Pietzsch, Jean-Yves Tinevez
>> Cc : imagej-devel at imagej.net
>> 
>> Hi all,
>> 
>>  I wanted to share a brief case study on the current dependency skew of ImgLib2-algorithm-related components.
>> 
>>  Last week, an innocent-looking commit was merged into imglib2-algorithm. It then made its way into a patch release of imglib2-algorithm, and patch release of pom-imagej. Unfortunately, even a trivial package move like this is actually a breaking API change, and both the component and pom releases should have incremented a major version to indicate this.
>> 
>>  Further, pom-imagej now declares a set of components that are incompatible with each other - as components downstream of imglib2-algorithm are not updated to use the new packages. Thus if these libraries were consolidated (e.g. to upload to Fiji), there would be hit by dependency skew.
>> 
>>  For those interested, there are two possible solutions:
>> 
>> 1) Track down all uses of the old packages, update them, cut releases, update pom-imagej.
>> or
>> 2) Add deprecated, trivial extensions of the moved classes back to the old locations, which can then be removed at a later date.
>> 
>>  Naturally, #2 is much simpler and thus looking more attractive right now. :) Either way, developers should be aware of the current problems with pom-imagej 5.12.3 and 5.13.0 (the latter also points to an unreleased ij1-patcher, due to incompatibilities with ImageJ 1.49p - so certainly don't use that one).
>> 
>>  Our versioning practices are on the wiki: http://imagej.net/Architecture#Versioning but please let us know if anything is unclear or hard to find.
>> 
>>  The burden of manually accounting for SemVer changes is hopefully one we will soon be free from. For now, it's just something we have to consider whenever we cut releases.
>> 
>> Best,
>> Mark
> 
> 
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagej.net
> http://imagej.net/mailman/listinfo/imagej-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20150317/1ac12b5f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20150317/1ac12b5f/attachment-0001.pgp>