ome/omero-cli-transfer

Version compatibility

Closed this issue · 4 comments

joshmoore commented

During the presentation yesterday of a POC to the iRODS imaging WG meeting, I realized in a slow-mo sort of way, that if this script is the beginning of using omero transfer for archiving data (e.g., to iRODS) that the versioning issue is back on the table, i.e.:

  • OMERO A has omero-transfer v1 installed
  • User backs up Image B to iRODS as C.tar
  • User deletes Image B
  • User unpacks C.tar either:
    • to OMERO D with a different version
    • or the same happens on OMERO A after some upgrades
  • Potential 💥
erickmartins commented

Do you see this more of a problem with cli-transfer versioning or OMERO versioning?

I don't really have a good answer to this - there's no easy way to ensure full version compatibility on the cli-transfer side of things (in particular, I'm thinking about the transition from using CommentAnnotations to XMLAnnotations). I think future transitions become easier - we can version schemas for the XMLAnnotations and the OME data model, so it's less of a big deal. But yeah - any thoughts welcome.

joshmoore commented

I don't think of it as an OMERO versioning problem, at least as far as OMERO doesn't have a "versioned export format". transfer is basically becoming an "export" format, so the question will be: is it versioned? Options that we've touched on:

  • pass, all bets are off
  • you have to use the right version of transfer with any particular archive
  • transfer tries to support older archives

for the last point, sub-options I can think of include:

  • auto-upgrade XML using XLST like OME-TIFF does
  • maintain per version handlers in the same code base
erickmartins commented

I think the third option is very feasible for everything after 1.0: either sub-option is pretty ok if we have ome-types for almost all of it and versioned schemas for the things that are not there. I think continuing support for pre-1.0 packs is a losing proposition, to be honest - a world where we have

  • packs generated by >=1.0 can be unpacked by any version >= version used for packing
  • packs generated by <1.0 can only be unpacked by their own version
    is pretty ok!
  • 👍1
joshmoore commented

MSTM