>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 <hi...@wisc.edu> > *Envoyé :* lundi 16 mars 2015 20:38 > *À :* Tobias Pietzsch <pietz...@mpi-cbg.de>, Jean-Yves Tinevez > <tine...@pasteur.fr> > *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 > <https://github.com/imglib/imglib2-algorithm/commit/e1460f140a0b03554fcb6f3d14ca43362d7d86a5> > was merged into imglib2-algorithm. It then made its way into a patch > release of imglib2-algorithm, and patch release of pom-imagej > <https://github.com/imagej/pom-imagej/commit/d28f954494f76898d80296b168b5352238d25915>. > 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
