[ImageJ-devel] Breaking API changes and BOM version bumps
hiner at wisc.edu
Mon Mar 16 18:03:30 CDT 2015
>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
Potentially affected components that I know of:
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.
On Mon, Mar 16, 2015 at 4:43 PM, Tobias Pietzsch <pietzsch at mpi-cbg.de>
> 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,
> 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
> 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.
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ImageJ-devel