
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Johannes and Curtis,<div><br><div><blockquote type="cite">certainly you saw Curtis' recent mail about our plans for ImageJ2?<br></blockquote>I must have missed that. Can you send a link?<br><br></div><div>First of all: in principle, I have no problem with that if it is necessary.</div><div>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.)</div><div><br></div><div>That being said, here are my concerns and questions:</div><div><br></div><div>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 <a href="https://github.com/imglib/imglib/pull/23">https://github.com/imglib/imglib/pull/23</a> (last 10 messages or so).</div><div>How can we pull this off consistently?</div><div><br></div><div>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?</div><div>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.</div><div>Overall, I'm a bit afraid of the additional overhead.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>One more thing: If you want to bring imglib core out of beta, we should probably do a clean-up.</div><div>There are things that are in core now, I would not consider ready for release (ROIs come to mind).</div><div>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).</div><div><br></div><div>Stephans, what do you think?</div><div><br></div><div><br></div><div>best regards,</div><div>Tobias</div><div><br><div><div>On Apr 7, 2014, at 11:06 PM, Johannes Schindelin <<a href="mailto:schindelin@wisc.edu">schindelin@wisc.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi Tobias, Stephan & Stephan,<br><br>certainly you saw Curtis' recent mail about our plans for ImageJ2?<br>Basically, we want to release a version of ImageJ whose user interface<br>looks like ImageJ1, but internally uses all the goodies on which we worked<br>so hard these past years.<br><br>That includes ImgLib2, of course, so we would need to bring parts of<br>ImgLib2 out of beta. In particular, we found it unwise to always version<br>all of ImgLib2 in unison. Rather, there should be releases of the<br>individual components whenever there should be new releases: bug fixes,<br>API enhancements, API-breaking major new developments.<br><br>As always, Curtis & I are ready to help with all of that stuff, in<br>particular with helpers making release engineering close to fun. Our<br>central goal in that respect is to make it as easy as possible to switch<br>between A) reproducible builds with release couplings; and B)<br>tightly-coupled builds with snapshot couplings for rapid development<br>across components.<br><br>The first step would be to break the multi-module ImgLib2 repository apart<br>(much in the way we split out imglib2-tests and friends, except that we<br>split out *all* of the individual projects). We do not see any other way<br>to get only that part of ImgLib2 out of beta that we really need for the<br>ImageJ2 release...<br><br>Are you okay with that plan?<br><br>Ciao,<br>Dscho<br><br>P.S. We are planning to split up imagej.git in very much the same way.<br><br></blockquote></div><br></div></div></body></html>