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

[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.