Hi Mark, imglib2-tests and imglib2-algorithm-gpl are fixed already.
I’ll check BDV and TrackMate tommorrow. all the best, Tobias On 17 Mar 2015, at 00:03, Mark Hiner <hi...@wisc.edu> wrote: > >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 <pietz...@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, <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 > > > _______________________________________________ > ImageJ-devel mailing list > ImageJ-devel@imagej.net > http://imagej.net/mailman/listinfo/imagej-devel
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ ImageJ-devel mailing list ImageJ-devel@imagej.net http://imagej.net/mailman/listinfo/imagej-devel
