Hi Tobias, Stephan & Stephan, certainly you saw Curtis' recent mail about our plans for ImageJ2? Basically, we want to release a version of ImageJ whose user interface looks like ImageJ1, but internally uses all the goodies on which we worked so hard these past years.
That includes ImgLib2, of course, so we would need to bring parts of ImgLib2 out of beta. In particular, we found it unwise to always version all of ImgLib2 in unison. Rather, there should be releases of the individual components whenever there should be new releases: bug fixes, API enhancements, API-breaking major new developments. As always, Curtis & I are ready to help with all of that stuff, in particular with helpers making release engineering close to fun. Our central goal in that respect is to make it as easy as possible to switch between A) reproducible builds with release couplings; and B) tightly-coupled builds with snapshot couplings for rapid development across components. The first step would be to break the multi-module ImgLib2 repository apart (much in the way we split out imglib2-tests and friends, except that we split out *all* of the individual projects). We do not see any other way to get only that part of ImgLib2 out of beta that we really need for the ImageJ2 release... Are you okay with that plan? Ciao, Dscho P.S. We are planning to split up imagej.git in very much the same way. _______________________________________________ ImageJ-devel mailing list ImageJ-devel@imagej.net http://imagej.net/mailman/listinfo/imagej-devel
