<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id=":1jk" style="overflow:hidden">
- a pull request into whichever repository houses the specification<br>
(currently bioformats.git)<br>
- creation of "release" artifacts from whichever repository houses the<br>
specification<br>
- a pull request into ome-xml.git (to update the autogenerated code)<br>
- creation of release JARs from ome-xml.git<br>
- a pull request into scifio.git (to update SCIFIO readers)<br>
- creation of release JARs from scifio.git<br>
- a pull request into bioformats.git (to update Bio-Formats readers)<br>
</div></blockquote></div><br></div><div class="gmail_extra">Nitpicky: there won't be a dependency on OME-XML in SCIFIO, so for this example that step can be omitted.<br><br></div><div class="gmail_extra">Also, the creation of artifacts would all be automated, right...?<br>
<br>Conceivably, version number bumping could be automated as well... I believe Johannes made a script to do that for pom-scijava.<br></div><div class="gmail_extra">Having a parent equivalent <a href="https://github.com/scijava/scijava-common/tree/master/pom-scijava">pom-scijava</a> for all these repositories would simplify things as well, as you would only need to update one direct dependency, and the versions for the rest of the components would be derived. So it's really not that much bookkeeping.<br>
<br></div><div class="gmail_extra">Modifying the top layer of the stack does require several updates, but - and someone please correct me if I'm wrong here - conceivably you only need to make one PR like this per project per release cycle.. and it would just be part of the release process, when you're doing a commit to bump version numbers anyway. Also I suspect there are additional git/maven options to simplify things here.<br>
<br></div><div class="gmail_extra">Anyway, I personally am already working with a 3-deep dependency chain with SCIFIO to IJ2:<br></div><div class="gmail_extra">SCIFIO <-> imglib -> ImageJ2<br><br></div><div class="gmail_extra">
But locally I just set my dependencies to the SNAPSHOT version (which is easy to do if you have that parent pom, because you just need to <a href="http://stackoverflow.com/questions/13876165/how-to-override-maven-property-in-command-line">override </a>its <a href="https://github.com/scijava/scijava-common/blob/master/pom-scijava/pom.xml">properties</a>) and develop normally. For ant builds, we could have Maven generate the dependency jars automatically. I'm going to have to put some more work into artifact generation anyway to get a loci_tools.jar with proper sez-poz annotations.. so it's an area I'll be working on.<br>
<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div class="gmail_extra">Our policy so far has been to release everything at once<br></div>
</blockquote><div class="gmail_extra"><br></div><div class="gmail_extra"> I don't see why you couldn't release all at once still.. the action of releasing multiple components may not be atomic, but there's no reason we can't say "I'm releasing Bio-Formats, SCIFIO and OME-XML on July 11th"... right?<br>
<br></div><div class="gmail_extra">It also avoids unnecessary versioning.. like "releasing" a new fork even though nothing has changed. I guess I don't know here.. looking at the git log.. do version numbers change for every component on every release, even if nothing changed within that component? My assumption was that they do.. but maybe I'm wrong.<br>
<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
Note that we've previously (and relatively recently) put quite a bit of<br>
effort into getting the OME-XML code and specification into bioformats.git.<br></blockquote><br></div><div class="gmail_extra">This is a fundamental SCIFIO thing... the proposed structure of SCIFIO has always been:<br><br>
</div><div class="gmail_extra">SCIFIO.jar (open format readers/writers)<br> |<br></div><div class="gmail_extra">OME-XML.jar (OME-XML classes, OME-XML metadata class, translators to/from core SCIFIO formats & OME-XML)<br>
</div><div class="gmail_extra"> |<br>Bio-Formats.jar (proprietary formats, translators to/from proprietary formats & OME-XML)<br><br></div><div class="gmail_extra">I admit I have not been keeping up as well as I'd like with Bio-Formats development, because I've been splitting my time between SCIFIO and IJ2 this past month. But, given this hierarchy, I think the OME-XML project clearly has value on its own, and it makes sense to be able to separate it from Bio-Formats under the SCIFIO design (even though it's an integral part of the openmicroscopy/bio-formats.git right now).<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">Anyway, I agree this would be a non-trivial change, but I think it creates a cleaner and more modular software stack, and could add more meaning to version numbers (and, if versions <b>are </b>always updated regardless of work, this would eliminate unnecessary commits).<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">I will almost certainly be doing this split in scifio.git regardless, so maybe that will be helpful to test the waters and see what the workflow actually is like..?<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">- Mark<br></div></div>