3.1 release plan

[d-v-b]

I'd like to use this discussion to sketch out a plan for a 3.1 release. This would be our first post-3.0 release with some breaking changes, so we should be sure that people know what's coming.

Proposed changes for 3.1

I've created a 3.1 milestone, which so far is only labelled with PRs from me, but we should discuss which other efforts should be targeted for a 3.1 release. From my POV the main thing is the dtypes refactor, but we might want to slide other things in: for example, we may want to change some deprecation warnings to be more explicit about when the deprecated API will be removed (we can change language like "foo will be removed in the future" to "foo will be removed in the 3.2 release", for example. And I don't think there's a PR for this, but we should rethink our config (IMO an untyped, global, mutable dict is not ideal).

Should we have a 3.1 branch

Should we have a 3.1 branch? This would be convenient because we could merge PRs destined for 3.1, but it adds some complexity to our git workflow. Curious to hear people's thoughts here

Pre-release activities

We should notify downstream users about this release, and we should issue a pre-release so we have time to sand off any sharp edges. In particular I think #2874 will benefit from hands-on testing.

[d-v-b]

@zarr-developers/python-core-devs any thoughts here? in particular about the 3.1 branch idea

[d-v-b]

i created a 3.1.0 branch

[dstansby]

Not having a branch will make things a lot simpler, but once the first PR for 3.1 is merged to main it will prevent us making any more bugfix releases until we release 3.1. So if we do this, we should make sure the time between "first PR for 3.1 merged" and "3.1 release" is as short as possible.

Another consideration is support - are we planning on supporting 3.0.x for a period after 3.1 is released? If so we will need a branch anyway.

[marek-kan]

Hi all,
I hope this is the right place to ask, please redirect me if I should post elsewhere.

I’m planning a new project based on Zarr 3, but need support for float16, int8, uint8, and bool dtypes - which are included in #2874 if I am not mistaken. I understand release timelines can be hard to pin down, if you can share whether 3.1 is expected in the next month, quarter, or half-year, it would really help me plan.

I will also check the contribution guide to see if I can help in any way.

Thanks so much for all your hard work on Zarr, really appreciate the effort!

[d-v-b]

@marek-kan those data types are already supported in zarr-python. see

zarr-python/src/zarr/core/metadata/v3.py

Lines 436 to 449 in f674236

	BOOL_DTYPE = Literal["bool"]
	BOOL = np.bool_
	INTEGER_DTYPE = Literal["int8", "int16", "int32", "int64", "uint8", "uint16", "uint32", "uint64"]
	INTEGER = np.int8 | np.int16 | np.int32 | np.int64 | np.uint8 | np.uint16 | np.uint32 | np.uint64
	FLOAT_DTYPE = Literal["float16", "float32", "float64"]
	FLOAT = np.float16 | np.float32 | np.float64
	COMPLEX_DTYPE = Literal["complex64", "complex128"]
	COMPLEX = np.complex64 | np.complex128
	STRING_DTYPE = Literal["string"]
	STRING = np.str_
	BYTES_DTYPE = Literal["bytes"]
	BYTES = np.bytes_
	ALL_DTYPES = BOOL_DTYPE | INTEGER_DTYPE | FLOAT_DTYPE | COMPLEX_DTYPE | STRING_DTYPE | BYTES_DTYPE

. #2874 is simply defining a new implementation of those data types, and #2874 should not change the user-facing API for creating arrays with those data types. So I think you are safe to start working on your project with the current version of zarr-python.

As for timing the release, we definitely want to be done within the next few weeks.