Hi Johannes and Curtis, > certainly you saw Curtis' recent mail about our plans for ImageJ2? I must have missed that. Can you send a link?
First of all: in principle, I have no problem with that if it is necessary. I would just ask that Curtis or you explain for a half hour or so these magic release engineering helpers over skype. (It would by the way also be nice to know how this currently works. I have no idea, how I would do a "proper beta release" if I wanted to do so… I would appreciate some pointers to documentation or scripts etc.) That being said, here are my concerns and questions: My fear with splitting subprojects is that this will make it harder to consistently refactor across subprojects, (or clean up behind commits that don't), see this discussion https://github.com/imglib/imglib/pull/23 (last 10 messages or so). How can we pull this off consistently? Also I image that we will require quite a bit more of "git logistics" with split projects. For example, assume that I want to make a new topic branch that touches more than one subproject (which easily happens when refactoring). Will I have to make topic branches in all subprojects? Is there a way to relate these other than manually by using the same branch names across projects, etc? How will Jenkins deal with this decoupled situation: I will merge my topic branches into master in each of the subprojects sequentially. This will produce a lot of failing intermediate builds in Jenkins, right? I think this will complicate hunting down errors. Overall, I'm a bit afraid of the additional overhead. How about doing decoupled versions without splitting up the git repository? It seems to me that this would be an easy way to avoid the downsides mentioned before. One more thing: If you want to bring imglib core out of beta, we should probably do a clean-up. There are things that are in core now, I would not consider ready for release (ROIs come to mind). So either we live with rapidly growing major version numbers due to frequent API breaks (fine with me) or split out the not-quite-ready parts into their own subprojects (also fine with me). Stephans, what do you think? best regards, Tobias On Apr 7, 2014, at 11:06 PM, Johannes Schindelin <schinde...@wisc.edu> wrote: > 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. >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ ImageJ-devel mailing list ImageJ-devel@imagej.net http://imagej.net/mailman/listinfo/imagej-devel
