Update release.rst for the upcoming release - 2.15.0

[MSanKeys963]

Updated the release.rst for the upcoming 2.15.0 release. Please have a look.

CC: @joshmoore

TODO:

• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[MSanKeys963]

Does any of the @zarr-developers/python-core-devs want to have a look at this and assist with the 2.15.0 release?
I'd appreciate it.

[codecov]

Codecov Report

Merging #1378 (358e12a) into main (4b0705c) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##              main     #1378   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           36        36           
  Lines        14799     14803    +4     
=========================================
+ Hits         14799     14803    +4     

see 3 files with indirect coverage changes

[martindurant]

Is this waiting on anything?

[martindurant]

@jakirkham @joshmoore - now this is in, we should actually release. I have never released zarr before, but I can have a go if no one else is available.

[MSanKeys963]

Hi, @martindurant.

I had a quick chat with @jakirkham yesterday, and we're thinking of going with an alpha release (2.15.0a1) rather than 2.15.0 since #1131 just got in.

What do you think?

[martindurant]

Honestly, I don't think anyone will try an alpha that wouldn't be happy to install directly from github.

[martindurant]

Since 2.15.0 isn't tagged yet, why not just include the extra PR? It's opt-in, won't change behaviour for users.

[MSanKeys963]

@joshmoore, @jakirkham and @rabernat: Any thoughts here?

[joshmoore]

If it's in before the tag, then it's definitely "included". It will need the release notes though.

[jakirkham]

For context, Sanket and I discussed releasing.

Had suggested we go with an alpha to kick the tires on the changes in PR ( #1131 ). That way we are not beholden to a particular API (should it need reworking). This is a release pattern we have followed in the past.

Suppose other ways to accomplish this would be to mark that API as experimental in the docs and possibly elsewhere (at least until we've gotten more confidence with it)

Maybe there are other approaches

[jakirkham]

Raising an issue to discuss releasing ( #1401 )