Simplify releasing documentation

[pquentin]

Following @njsmith's procedure here: https://gitter.im/python-trio/general?at=5ec36d49940fa238d6fffa33

[codecov]

Codecov Report

Merging #1535 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #1535   +/-   ##
=======================================
  Coverage   99.67%   99.67%           
=======================================
  Files         108      108           
  Lines       13331    13331           
  Branches     1011     1011           
=======================================
  Hits        13288    13288           
  Misses         28       28           
  Partials       15       15           

[oremanj]

I think it would be a good idea for someone to approve the release PR before tagging and uploading to PyPI. It's our last chance to catch silly newsfragment typos and such. I don't feel strongly though, if others think this is too much process.

[smurfix]

In the past we uploaded after merging the PR. That's not more process, let alone too much, but just a different (and IMHO safer) order of doing things.

[njsmith]

We already review the newsfragments before they're merged in the first place, typos are rarely catastrophic, and do have the option of retroactively fixing the changelog in future releases if we really want to.

I don't have anything against process per se, but I feel like it should have a clear motivation and guidelines for what to do, and in this case I'm not quite sure what those are. Except that, well, releasing is scary, and more process feels safer than less process :-). But IME vague "this is scary" process tends to be counterproductive.

That said, when I'm releasing I do tend to skim over the changelogs since they're in front of me and sometimes rewrite bits. And if you do actually change them, then that's a clear thing you might want some review on!

In the past we uploaded after merging the PR. That's not more process, let alone too much, but just a different (and IMHO safer) order of doing things.

I don't have a strong feeling either way here, but generally you're going to be doing all these within a few seconds of each other, right? Is there a realistic risk that you're going to notice some catastrophic error in between hitting merge and hitting enter on the twine upload?

[njsmith]

I tend to do:

git clean -xdf   # maybe run 'git clean -xdn' first to see what it will delete
python3 setup.py sdist bdist_wheel
twine upload dist/*

Historically twine was better than setup.py upload, but I don't know if that's still true.

[pquentin]

This is what I use too! Updated

[njsmith]

You can post an approving review if you want, but I don't know if it actually does anything :-). We don't have github set to enforce approvals before merge. (Actually, now that I think about it, I think you may not even be able to post an approval on your own PR?)

[pquentin]

Right, we can't approve our own PRs, but we can merge them, fixed

[pquentin]

I don't have a strong opinion either way 🤷

But I updated the review comments, please take another look