Repository navigation
Conversation
Automated Review URLs |
Co-authored-by: Josh Moore <josh@openmicroscopy.org>
Co-authored-by: Josh Moore <josh@openmicroscopy.org>
|
This pull request has been mentioned on Image.sc Forum. There might be relevant details there: https://forum.image.sc/t/ngff-weekly-dev-update-thread/110810/162 |
|
☝🏽 Note the timer ⏲️ of one week for the merge on this so that we can open the comment period. |
|
|
||
| ### Dataset version metadata | ||
|
|
||
| OME-Zarr datasets record the complete OME-Zarr specification version, including the major, minor, and patch level, in their Zarr JSON. This identifies the specification version according to which the dataset was written. |
There was a problem hiding this comment.
suppose an implementation can write data consistent with a range of minor versions, say 1.2, 1.3, and 1.4. it writes a dataset that only uses features from 1.3. which version of the spec does it declare in zarr.json? if the answer is 1.3, then this places a burden on implementations to track exactly which features map to which minor version. if the answer is 1.4, the metadata is misleading.
There was a problem hiding this comment.
If every feature added in a 1.x version is added in the form of an extension (that's a big if as this has not really been discussed yet), then the extension management layer would provide what's needed to keep track of the minor version in which a given extension has been added.
There was a problem hiding this comment.
this burdens implementations with an obligation they might fail to uphold, so it might be worth reconsidering. putting a semver version in a json data model is not something I have seen work well; rather I have seen it fail, and there's a reason zarr itself only uses a version field for the major format version, and practically none of the parametrized data types, codecs, chunk grids, etc declare a version at all
|
|
||
| #### Supporting multiple versions | ||
|
|
||
| An implementation MAY support multiple OME-Zarr specification versions simultaneously. An implementation SHOULD make clear which versions it supports. An implementation MUST write datasets against one explicit specification version at a time, rather than producing a dataset that ambiguously mixes specification versions. |
There was a problem hiding this comment.
Would we foresee requiring collections to have consistent versions across all nodes. That appears like a hard requirement to me. It should be valid to e.g. refer to a 1.0 image collection hosted at the BIA & a 1.2 image somewhere else, no?
If I process these 2 images when OME-Zarr 1.4 is out and e.g. create a new label image for both images, would we expect that label to be in:
- 1.4 (always newest supported)
- One in 1.0, one in 1.2 (matching the image it was derived for)
- Something else?
My default for an implementation so far would have been to match the version of label images to the version of the image it is derived from.
Adds the draft for RFC-13 based on work done previously on GoogleDocs by @vuhlmann @joshmoore @gouttegd and @DragaDoncila
Commits (please squash):