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

[Tobias Pietzsch]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20150316/a4f316b3/attachment.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/20150316/a4f316b3/attachment.pgp>