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

[Mark Hiner]

>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 <hiner at wisc.edu>
> *Envoyé :* ‎lundi‎ ‎16‎ ‎mars‎ ‎2015 ‎20‎:‎38
> *À :* Tobias Pietzsch <pietzsch at mpi-cbg.de>, Jean-Yves Tinevez
> <tinevez at pasteur.fr>
> *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
> <https://github.com/imglib/imglib2-algorithm/commit/e1460f140a0b03554fcb6f3d14ca43362d7d86a5>
>  was merged into imglib2-algorithm. It then made its way into a patch
> release of imglib2-algorithm, and patch release of pom-imagej
> <https://github.com/imagej/pom-imagej/commit/d28f954494f76898d80296b168b5352238d25915>.
> 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/06354095/attachment.html>