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

[tinevez at pasteur.fr]

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/5e779923/attachment-0001.html>