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

Mark Hiner hiner at wisc.edu
Mon Mar 16 14:38:39 CDT 2015

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...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20150316/7b28654f/attachment.html>

More information about the ImageJ-devel mailing list