diff --git a/rfc/2/index.md b/rfc/2/index.md index d97653a2..e2c6051b 100644 --- a/rfc/2/index.md +++ b/rfc/2/index.md @@ -122,8 +122,8 @@ However, in the future they might deprecate support for version 2 or deprioritiz Additionally, there are OME-Zarr implementations that have their own integrated Zarr stack. With this hard cut, implementations that only support OME-Zarr versions ≥ 0.5 will not need to implement Zarr version 2 as well. -From a OME-Zarr user perspective, the hard cut also makes things simpler: < 0.5 => Zarr version 2 and ≥ 0.5 => Zarr version 3. -If users wish to upgrade their data from one OME-Zarr version to another, it migration tools will be available ([prototype here](https://github.com/scalableminds/zarrita/blob/8155761/zarrita/array_v2.py#L452-L559)). +From an OME-Zarr user perspective, the hard cut also makes things simpler: < 0.5 => Zarr version 2 and ≥ 0.5 => Zarr version 3. +If users wish to upgrade their data from one OME-Zarr version to another, migration tools will be available ([prototype here](https://github.com/scalableminds/zarrita/blob/8155761/zarrita/array_v2.py#L452-L559)). Migration is a fairly computationally cheap operation, because only json files are touched. Due to the existence of large quantities of images in OME-Zarr 0.4, it is RECOMMENDED that implementations continue to support OME-Zarr 0.4 with the underlying Zarr v2. @@ -222,7 +222,7 @@ While the metadata of Zarr v3 is not backwards compatible, the chunk data is lar Previous versions of this proposal contained changes to referencing `labels` in the OME-Zarr metadata. This has been delayed to future RFCs. -Previous versions have used a versioned namespace, e.g. `https://ngff.openmicroscopy.org/0.5`, in the Zarr attributes instead of a simple `ome` namespace with dedicated `version` attribute. +Previous versions of this proposal have used a versioned namespace, e.g. `https://ngff.openmicroscopy.org/0.5`, in the Zarr attributes instead of a simple `ome` namespace with dedicated `version` attribute. This has been abandoned because it makes discovery of versions more difficult. Additionally, handling of multiple versions may be ill-defined.