issue_comments

My messing around with tags seems to have been successful. The docs successfully build and been updated: http://xarray.pydata.org/en/stable/whats-new.html

It looks like the conda-forge update is also in progress: https://github.com/conda-forge/xarray-feedstock/pull/27 (thanks @jhamman and @ocefpaf !)

I'm going to push another version of the 0.10.1 tag to GitHub that includes fixes to doc/environment.yml (https://github.com/pydata/xarray/commit/20207fd45280a3cb0f2ca3bdef693f47b1880dca and https://github.com/pydata/xarray/commit/f530e668fa50665245988be2a00748b9b3ccc0a8).

This will allow us to actually build docs for 0.10.1 on ReadTheDocs.

I just pushed the release to pypi.

I'm dealing with the RTD build now, which seems to have broken without us noticing!

@Zac-HD Thanks for raising these concerns! I agree there are only upsides to a faster release cycle, and three months is way too long given the long back-log of improvements we have. Even without more automation, we should not wait more than 2-4 weeks between releases unless there are breaking changes in process (which can sometimes require more refinement to get right).

I think the trouble is that it's easy to get in a bad pattern of waiting for "just one more pull request" before issuing a new release. This is self-reinforcing -- the fewer releases we have, the more important it is to wait for a pull request before issuing a release.

I'd love to explore a more automated release pipeline. Take a look here for our current release instructions: https://github.com/pydata/xarray/blob/master/HOW_TO_RELEASE

In my experience, the slowest step is clean-ups/fixes of the "what's new" docs page (e.g., what I just did in https://github.com/pydata/xarray/pull/1940). It's hard to do that as part of the regular PR process in part because we only see built docs after PRs are merged. That said, if we do this more regularly the work required decreases (I spent about half an hour on this today). Unfortunately, there is no automated substitute for a human looking over a document to verify that it looks right :).

The actual release issuing process is quite fast once you know what you're doing, taking as little as half an hour minutes to update pypi, ReadTheDocs and conda-forge. But it would certainly be great if anyone (even non-maintainers) is capable of triggering this with a simple PR. Ideally, we should be able to issue a release anytime someone is willing to put in the effort of looking things over and ensuring the docs look right.

Anyways, my plan is to issue a release later today or tomorrow, as soon as #1940 is merged. There are lots of other excellent improvements in the pipeline (rolling window improvements, distributed writes to netCDF files, etc.) but we should just issue another release when those get merged instead of holding things up!