0.13.0 release

[max-sixty]

What do we think about a minor release soon?

My colleague just hit #3145 which reminded me the current release can make filing an issue confusing for folks

We've had a v good pipeline of changes in just a month: https://github.com/pydata/xarray/blob/master/doc/whats-new.rst#L18

I'm happy to help with this; ref #2998 (comment)

[shoyer]

There are couple of small fixes for sparse arrays with open pull requests. I would lean toward getting those in before the release.

One thing that would be especially helpful is finalizing some deprecations that have been open for a while, e.g., the removal of the inplace argument and sel_points().

[shoyer]

Also it would be great if you’d like to try going through the release process. We can potentially automate and/or remove some of those steps.

[max-sixty]

What do you think about writing a small script and deploying with an azure pipeline, triggering only on new tags? Could include the standard running tests etc. I'd need to look into how authentication re PyPI would work if done remotely. Or is this begging the xkcd cartoon?

[crusaderky]

Given that's 1 hour of work about once a month... Unless there is appetite for increasing the release frequency, I would say automation is overkill

[dcherian]

 4. On the master branch, commit the release in git:
      git commit -a -m 'Release v0.X.Y'
 5. Tag the release:
      git tag -a v0.X.Y -m 'v0.X.Y'
 6. Build source and binary wheels for pypi:
      git clean -xdf  # this deletes all uncommited changes!
      python setup.py bdist_wheel sdist
 7. Use twine to register and upload the release on pypi. Be careful, you can't
    take this back!
      twine upload dist/xarray-0.X.Y*
    You will need to be listed as a package owner at
    https://pypi.python.org/pypi/xarray for this to work.
 8. Push your changes to master:
      git push upstream master
      git push upstream --tags
 9. Update the stable branch (used by ReadTheDocs) and switch back to master:
      git checkout stable
      git rebase master

This bit seems easily scriptable

[max-sixty]

Yeah, automation is probably overkill if someone does it correctly each time – it does also mean hopefully no one makes a mistake / forgets a step

[shoyer]

My experience has been that the manual processes (e.g., checking release notes, finishing up deprecation cycles) take up most of the effort of issuing a new release. The commands 4-9 take about 5 minutes to run. I agree that the main value of automation there would be reducing the likelihood of manual mistakes.

It looks like there's an experimental documentation builder for pull requests with read the docs. It would be interesting to explore using it in xarray: https://blog.readthedocs.com/building-docs-for-pull-requests/

[max-sixty]

It looks like there's an experimental documentation builder for pull requests with read the docs. It would be interesting to explore using it in xarray: https://blog.readthedocs.com/building-docs-for-pull-requests/

Perfect - I emailed. Anything else like this, feel free to push onto us / me

[dopplershift]

The benefit to automation also makes it easier to distribute the workload to other people, helping with project sustainability. On my projects, I find it very nice that I make a new release on GitHub and packages appear on PyPI and the web docs are automatically updated to the new version.

[dcherian]

I find it very nice that I make a new release on GitHub and packages appear on PyPI and the web docs are automatically updated to the new version.

How do you do this? i.e. trigger PyPI and RTD updates with a tag on github?

[dopplershift]

On Travis I have some deploy hooks:

1. Using Travis' built-in PyPI support, it uploads wheels and sdist, only on tags
2. Execute a custom script to commit built docs to github pages (not RTD). On master builds, this updates dev docs. On a tag, it adds a new directory for that version of the docs.

Travis Config
Doc Deploy Script

[max-sixty]

FYI: we're on the waitlist for the RTD feature

[max-sixty]

FYI re RTD PR feature, too many PRs! :)

We are sorry, we can't enable the pull requests builder feature for your project right now. This is because the long build time and many active PRs of your project. We have limited resources, we are working in making the builds faster. We let you know when we can enable the feature for your project.

[fmaussion]

RTD is struggling with resources, and I can understand that. What is really annoying (and the problem is often the same on travis) is that the conda install is taking a huge part of the build process resources. See e.g. readthedocs/readthedocs.org#6025 , where I ended up using pip for very satisfying results (!).