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, <tine...@pasteur.fr> <tine...@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@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ ImageJ-devel mailing list ImageJ-devel@imagej.net http://imagej.net/mailman/listinfo/imagej-devel
