saalfeldlab / bigwarp

A tool for manual pointwise deformable registration using bigdataviewer.
GNU General Public License v2.0
25 stars 14 forks source link

Shipping advanced version from update site #80

Open tischi opened 4 years ago

tischi commented 4 years ago

Hi @bogovicj, I would like to ship the version with my latest additions from my Fiji update site: EMBL-CBA I guess, in order for this to work smoothly I should use a version number that is (a) larger than the one currently shipped with Fiji, such that my one will replace the current one, and (b) smaller than the one that you are planning to push to the official next Fiji release, such that it will overwrite my one. Do you have a suggestion for how to determine such a version number? This is the current one in Fiji: https://github.com/scijava/pom-scijava/blob/master/pom.xml#L537 That means I should use something larger than that...

bogovicj commented 4 years ago

Hi @tischi

Thanks for being patient :-/

There is a 5.1.0 release of bigwarp now, but not sure when it'll make it to fiji. I looked briefly into it last week, but there are some other dependencies that may also have to get bumped (and so I'm hesitant to do it without communicating carefully).

I think 5.0.2 would be safe, maybe 5.0.99 would be even safer. not sure

imagejan commented 4 years ago

@tischi wrote:

I should use a version number that is (a) larger than the one currently shipped with Fiji, such that my one will replace the current one, and (b) smaller than the one that you are planning to push to the official next Fiji release, such that it will overwrite my one.

I don't think the updater works like that, does it? In the past, updates from update site further down the list were able to override components from site further up, independent of the version (which also caused some breakages of update sites because they still served then-outdated versions of core components).

In short, the version currently only matters for the scijava-maven-plugin (and the copy-jars goal), but not in the Fiji/ImageJ updater.

@frauzufall or @ctrueden may correct me if this behavior has changed in the current updater.

In general, it would be good if the managed version in pom-scijava was kept up to date with the latest known-to-work version: https://github.com/scijava/pom-scijava/blob/master/pom.xml#L537

ctrueden commented 4 years ago

@imagejan is right. Any version of bigwarp_fiji uploaded to EMBL-CBA will override whatever is shipped on Fiji or Java-8. It can later be marked obsolete on EMBL-CBA, in which case the version from Java-8 will once again take precedence. But of course this requires some coordination across update site maintainers.

Would it help for us to upload bigwarp 5.1.0 to Java-8, along with its updated dependencies? I hate being the bottleneck to all this progress. It would be a little dangerous (no melting pot tests etc.), but in the interest of expedience?

bogovicj commented 4 years ago

Thanks @imagejan and @ctrueden ,

Would it help for us to upload bigwarp 5.1.0 to Java-8, along with its updated dependencies?

I'm not in a rush. Actually, I'm likely to do some more development on the soon side, so I may even lean toward waiting for a bit (for 5.1.1). Whether to push this through now depends on what @tischi and his users need / want.

tischi commented 4 years ago

Any version of bigwarp_fiji uploaded to EMBL-CBA will override whatever is shipped on Fiji or Java-8.

Wow... I did not know this. @ctrueden In fact I do not really know what the "normal" purpose of the Java 8 update site is. Could you maybe explain a bit?

imagejan commented 4 years ago

@tischi the Java-8 update site was created to allow supporting both Java-6 and Java-8 installations of Fiji during the transition to Java-8. Please read up on this here: https://imagej.net/2015-12-22_-_The_road_to_Java_8

tischi commented 4 years ago

Thanks! @ctrueden it is not urgent, maybe we can discuss during the hackathon (incl. Frau Zufall) about the best solution?