0.18.1 patch release?

[dcherian]

I think we should issue a patch release soon.

• xarray.map_blocks will break with new dask,distributed releases this week since we don't have a released version with Ensure HighLevelGraph layers are Layer instances #5271
• More robust guess_can_open for netCDF4/scipy/h5netcdf entrypoints #5296: fix for regression reported in Engine is no longer inferred for filenames not ending in ".nc" #5295
• Better error message when no backend engine is found. #5300: fix the error message in ds = xr.tutorial.load_dataset("air_temperature") with 0.18 needs engine argument #5291 so that it is more helpful. It's a key entry point for new users.
• failing RTD build #5299 RTD build is broken
• xarray 0.18.0 raises ValueError, not FileNotFoundError, when opening a non-existent file #5329 should throw FileNotFoundError error on nonexistent file?

Nice to have

• Add mode="r+" for to_zarr and use consolidated writes/reads by default #5252 zarr region
• Allow assigning values to a subset of a dataset #5045 assigning to subset
• Add drop_duplicates for dims #5239 drop_duplicates
• Raise error for invalid reference date for encoding time units #5288 invalid reference date error

Thoughts? Volunteers?

[shoyer]

I'm going to take a look into fixing #5291

[shoyer]

I'd also love to get #5252 in (it makes to_zarr() with region much faster / more efficient), but it's not really urgent.

[max-sixty]

I can "do the release" if that's helpful

[keewis]

I can also help with the release.

[dcherian]

shall we merge #5300 and release? Users are running in to the map_blocks issue, see #5331

[max-sixty]

This is done. I'll send an email & check the docs are working tomorrow. Let me know anything I missed!

[shoyer]

thanks Max!

We can always do a 0.18.2 for #5329 if need be :)

[dcherian]

Thanks Max! Looks like that went pretty smoothly!

[max-sixty]

From #4753 (comment)

I wonder if we should hold off on merging until after the 0.18.1 release -- or maybe just move to a date based versioning system / release cycle like dask.

I am keen on whatever lets us release faster and easier — very open to a set schedule.

Releasing has got to a place such that increasing the frequency isn't costly. The recent work by @andersy005 and others to automate PyPI has made that even more so. There are some smaller tasks we can put into pipelines if we want to squeeze more out there (e.g. updating stable branch, adding contributor lists). The only really necessary tasks are writing the summary, organizing the whatsnew, sending out communications.

There's an extreme end of "constantly release new main branches". I don't see anything functionally wrong with that, but I'm sure there are unexplored consequences, and I'm not sure our role is to forge a new path in OSS release cycles.

So maybe monthly is a reasonable balance?

[andersy005]

Glad to hear that releasing is getting easier/simpler :)

There are some smaller tasks we can put into pipelines if we want to squeeze more out there (e.g. updating stable branch, adding contributor lists). The only really necessary tasks are writing the summary, organizing the whatsnew, sending out communications.

I've been thinking about this, and I'm wondering if something like this great tool: github-activity could help us (at least with updating whatsnew.rst). github-activity is able to generate the changelog from the GitHub API. This would eliminate the need for updating whatsnew.rst multiple times (once for each PR). With proper labels, github-activity is able to categorize PRs and Issues during the changelog generation. Another cool feature of github-activity is that it includes other contributions in addition to the default PR submissions: https://github-activity.readthedocs.io/en/latest/#how-does-this-tool-define-contributions-in-the-reports

There's an extreme end of "constantly release new main branches". I don't see anything functionally wrong with that, but I'm sure there are unexplored consequences, and I'm not sure our role is to forge a new path in OSS release cycles.

I'm curious.. How are these "new main branches" different from git tags from releases?

So maybe monthly is a reasonable balance?

👍🏽 for frequent/monthly release cadence

[andersy005]

Here's one example that shows github-activity in action: https://jupyterbook.org/reference/_changelog.html

[max-sixty]

I'm curious.. How are these "new main branches" different from git tags from releases?

I had meant commit rather than branch — i.e. "on every commit to master". But as a thought experiment rather than a proposal