Apologies if this has been discussed already, but is there policy written down anywhere with respect tocode compatibility written against zarr 2.x? Concretely, I wonder if making this snippet using xarray is a design goal of zarr-python v3?

importxarrayasxrimportpathlibimportshutilp=pathlib.Path("out.zarr")shutil.rmtree(p,ignore_errors=True)ds=xr.tutorial.open_dataset("air_temperature")ds.to_zarr(p)

That runs fine with zarr 2.18.2; Should it work with zarr-python 3.x without modification to xarray? To give you an idea of the kinds of changes needed to make this work:

• store is passed as a positional arg, while it's keyword only on v3 (scikit-learn had a nice decorator for deprecating positional arguments, so if we wantstore to be keyword only we can deprecate it gracefully without too much effort)
• xarray usesAttributes.put(dict). Easy to alias to.update (with a deprecation if we want)
• xarray accesses various attributes from theGroup object (store, read_only, synchronizer). No idea if these still make sense in the v3 codebase.
• Group.create previously took some keyword arguments (shape, dtype, fill_value, chunks) that seem more like Array arguments. Reading throughzarr.v2.Group.create, I guess that creates an Array in the group, rather than a new group. Is that deliberate?

There's some additional examples of this in some issues (#2023,#2021)

One point worth discussing: is there value in code-level compatibility if zarr-python 3.x is (presumably) writing zarr-v3 by default? IMO yes, but perhaps not.