Update changelog and bump version for new release

[brainwane]

As a new maintainer of twine, here's what I believe I have to do in order to make a new release of twine. Please correct me if I'm wrong and tell me if I'm right.

• get maintainership of the repo on GitHub
• update docs/changelog.rst with the newest changes (done in Update changelog #308) and the new release (done in this PR)
• update the __version__ string in twine/__init__.py
• run python setup.py check -r -s to check that the long_description and other metadata will render fine
• run tox -e py{27,34,25,36} and tox -e pep8 to check tests haven't broken (I did this with all but Python 3.4, which I don't have installed yet)
• create a git tag for 1.10.0 per Ian's Update changelog and bump version for new release #306 (comment)
• create distributions with python setup.py sdist bdist_wheel
• get maintainership on our Test PyPI project and set my username/password with keyring (need privileges, username brainwane)
• upload to Test PyPI: twine upload --repository-url https://test.pypi.org/legacy/ --skip-existing dist/*
• verify that everything looks good, downloads ok, etc.
• get maintainership on our PyPI project and set my username/password with keyring (need privileges, username brainwane)
• On a Monday or Tuesday, release to canon PyPI with: twine upload --skip-existing dist/* (to someday in the future be superseded by tox -e release)
• send an announcement email to pypa-announce (need to subscribe and then get posting privileges)

[codecov]

Codecov Report

Merging #306 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master     #306   +/-   ##
=======================================
  Coverage   67.42%   67.42%           
=======================================
  Files          12       12           
  Lines         574      574           
  Branches       91       91           
=======================================
  Hits          387      387           
+ Misses        162      161    -1     
- Partials       25       26    +1

Impacted Files	Coverage Δ
twine/__init__.py	100% <100%> (ø)	⬆️
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 88341f7...3b29633. Read the comment docs.

[jaraco]

Works for me. I don’t have anything to add. Best of luck!

[sigmavirus24]

Please let's not use GitHub releases. They don't scale. They require manual process. They require people to upload binaries and as soon as one appears, downstream redistributors expect them to always be updated. They also hide the "releases" created by simply pushing tags. They confuse users. They're all around awful unless we're very consistent with them.

[brainwane]

OK! So I will figure out a git tag instead. Haven't done that before so any "here is how we do it" guidance is welcome.

@sigmavirus24 if you could add brainwane as a Maintainer for the twine project on test and regular PyPI, and tell me whether the rest of my checklist is right, I'd very much welcome that, as the PyPI accounts in particular are blockers for me.

[sigmavirus24]

git tag -sam 'Release v1.10.0' 1.10.0 is how I would tag this release.

• -s signs it with your PGP key
• -a creates an annotated tag for GitHub
• -m adds the message

[sigmavirus24]

I can add you later tonight

[sigmavirus24]

I added you to the package on testpypi and pypi.

Would tox -e release be more useful if we allowed posargs? We could then update it so that it looks like

[testenv:release]
# ..
commands =
    python setup.py -q bdist_wheel sdist
    twine upload --skip-existing {posargs} dist/

That would allow you to pass signing options to it. I'm not sure we need to upload signed packages for twine. Warehouse doesn't use the signatures or expose them for users to view.

My last item is the following:

There are a lot of very large projects and companies that rely on Twine. We obviously can't catch every regression or bug, so releasing on the weekend (or right before) is really inconvenient for those users. If at all possible, we should release on Monday or Tuesdays.

[brainwane]

Thanks @sigmavirus24.

I'll use the git tag syntax and will see if I can modify it to include a somewhat longer release note:

This release removes obsolete project registration usage text and updates --repository[-url] usage text, prints progress to stdout instead of stderr, improves the progressbar, and reorganizes and improves user and developer documentation.

Please see the changelog for detailed notes.

I know that right now Warehouse does not use or expose the signatures, but I am rather attached to signing packages for what I will freely admit are not-very-defensible hindbrain reasons ("but it's more secure!!1!"). So I'd appreciate the tox improvement you suggest.

And you're right, releasing on a Friday is setting myself up for headaches. I'll release to Test PyPI today to test the process, and then Monday or Tuesday I'll release 1.10.0 onto canon PyPI.

[sigmavirus24]

I will present the following case for not signing twine releases: There are three maintainers with three separate GPG keys and downstream redistributors, for however much they mean well, will throw tantrums if each of us releases and signs twine differently every time. Somehow, this always upsets them. I'd rather not lull them into a sense of us always signing releases, nor signing them with the same key.

I'd be interested to see what including that whole message in the release tag message does. I've no evidence that anyone actually reads it. I'm also not certain that GitHub will display it for us. It will be interesting to see what the results of your experimentation are. :)

[dstufft]

I think gpg signing on PyPI is a net negative for the ecosystem and I want very much to eliminate it.

[brainwane]

Understood. Thank you both. I shall refrain from signing this and other Twine releases.