New maintainer release checklist

[brainwane]

• Add readme-checking with readme-renderer to tox doc tests
• Add checklists for "add a new maintainer" and "cut a new release" to Contributing doc

This is really for my own use because I absolutely need a checklist for stuff like this. Followup to #306.

[codecov]

Codecov Report

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

@@           Coverage Diff           @@
##           master     #314   +/-   ##
=======================================
  Coverage   69.53%   69.53%           
=======================================
  Files          12       12           
  Lines         581      581           
  Branches       91       91           
=======================================
  Hits          404      404           
- Misses        149      150    +1     
+ Partials       28       27    -1

Impacted Files	Coverage Δ
twine/wininst.py	29.72% <0%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4a8c3d4...cc480ab. Read the comment docs.

[mauritsvanrees]

Thanks for making this checklist!
For testing zest.releaser this would work (testing with Python 2.7 here, but 3.6 should work too):

maurits@mauritsbook:tmp $ virtualenv test
New python executable in test/bin/python2.7
Also creating executable in test/bin/python
Installing setuptools, pip, wheel...done.
maurits@mauritsbook:tmp $ cd test
maurits@mauritsbook:test $ . bin/activate
(test)maurits@mauritsbook:test $ pip install --upgrade --pre --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple twine
...
(test)maurits@mauritsbook:test $ pip install --upgrade zest.releaser
...
(test)maurits@mauritsbook:test $ cd ~/own/mauritstestpackage/
$ fullrelease  # Note: this asks a few simple questions.
INFO: Starting prerelease.
...
INFO: Starting release.
Tag needed to proceed, you can use the following command:
git tag 1.24.4 -m u'Tagging 1.24.4'
Run this command (Y/n)? 
...
Upload to pypi (Y/n)? 
Uploading mauritstestpackage2-1.24.4-py2-none-any.whl
100%|██████████| 10.3k/10.3k [00:01<00:00, 6.79kB/s]
Uploading mauritstestpackage2-1.24.4.tar.gz
100%|██████████| 8.70k/8.70k [00:01<00:00, 7.73kB/s]
INFO: Starting postrelease.
...

It is best to test it out by releasing a real package. Above, I use a basically empty test package for that. zest.releaser uses your ~/.pypirc, so if you only have the test pypi index listed there, it should be fine to release any package.

You may want to force zest.releaser into creating a wheel, next to a plain sdist, by adding this to setup.cfg or ~/.pypirc:

[zest.releaser]
create-wheel = yes

But if you have [bdist_wheel] universal = 1 in setup.cfg, then it will already create wheels. (I can imagine that we make creating wheels as well the default at some point.)

[mplanchard]

As of the current master, pypiserver supports running tox with tox -e pre_twine to test all supported environments against the prerelease of twine, so you could automate with git clone [email protected]:pypiserver/pypiserver && cd pypiserver && tox -e pre_twine if desired!

Thanks again for reaching out! It's super, super nice to be able to be sure that new versions of twine aren't going to break things for our users.

[sigmavirus24]

@mplanchard does that mean you're also willing to be tagged into issues where this breaks things because of problems in pypiserver? Alternatively, is there a stable branch that can be tested against?

[mplanchard]

@sigmavirus24 absolutely! I'd definitely prefer to know and fix things prior to it becoming a problem outside of the pre-release world. Generally, master is our stable branch, and the source of our deployments when we do releases, so testing against that is preferred.

[brainwane]

Thanks, @mauritsvanrees, @mplanchard, and @hpk42 for help here and in IRC. I've added your advice to this checklist.

Of course, I'm also open to maintainers of other packaging/distribution tools speaking up, here or in new GitHub issues in this repo, to tell me what steps I could add to this release checklist to find out early if Twine breaks something for you. (We keep our master branch in a reasonably release-ready state, so you could also feel free to test against that in your own setups!)