Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dealing with versioning #1

Open
tischi opened this issue Sep 12, 2022 · 5 comments
Open

Dealing with versioning #1

tischi opened this issue Sep 12, 2022 · 5 comments
Labels
question Further information is requested

Comments

@tischi
Copy link
Collaborator

tischi commented Sep 12, 2022

@joshmoore @sbesson

I assume you have a lot of experience with dealing with multiple versions.

Do you already envision a way of representing the multiple version of OME-Zarr on the Java side? Taking the multiscales as an example?!

I could also lay out different ways that I could imagine, but, as I have no experience with this, I think it makes more sense if you present your view first.

@tischi tischi added the question Further information is requested label Sep 12, 2022
@sbesson
Copy link
Member

sbesson commented Sep 13, 2022

I assume you have a lot of experience with dealing with multiple versions.

The answer is probably yes and no.

If I understand the intent of this library, the existing repository with the closest intent is https://github.com/ome/ome-model and the ome-xml Java component which contains code-generated classes for all elements defined in the OME-XSD schema - see https://javadoc.io/doc/org.openmicroscopy/ome-xml/latest/index.html

Importantly, this component does not support multiple versions of the OME schema but tracks the latest version. This is why the release of a new version of the OME-XSD has such impact on the OME stack as breaking version of this component and all the downstream ones are required.

The ome-zarr-py explored another paradigm to support reading/writing from multiple versions of the OME-NGFF. There are likely various patterns that could be reviewed and reused like the usage of versioned classes https://github.com/ome/ome-zarr-py/blob/master/ome_zarr/format.py i.e. MultiscalesV01, MultiscalesV02...

@tischi
Copy link
Collaborator Author

tischi commented Sep 13, 2022

i.e. MultiscalesV01, MultiscalesV02...

That's the pattern that also @tpietzsch suggested. If you made good experiences with that, why not?

  1. Combined with a JSONDeserializer that picks the right one based on the version string in the JSON?!
  2. And down-stream code only support that latest, assuming that older ones are converted into the latest?

@joshmoore
Copy link
Member

I'm not sure another library will be able to do the automatic detection of version, but I assume our library will be able to encapsulate that. And yes, I'd imagine some form of "upgrade chain" will let clients get to the "latest version that I support".

@tischi
Copy link
Collaborator Author

tischi commented Sep 14, 2022

Ok!

How do we proceed practically?

Shall I put my current code into a branch and we iterate on that?

Or do you have code already?

@joshmoore
Copy link
Member

I think putting your code here is a fine place to start (since I don't have any other code). The version detection I would "steal" from ome-zarr-py. The code generation that I was discussing will take me a bit longer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants