workflows: add a release workflow

[woodruffw]

This adds a release workflow that runs on a release: published event, with both PyPI uploading (via trusted publishing) and code signing (via Sigstore). I kept the latter because I copied this from some other projects that I use the same workflow on, but I'm happy to remove it in the interest of keeping things minimal to begin with.

Also, correcting myself from earlier: it looks like I don't have permissions to register the trusted publisher on the PyPI side:

Given that, I'll mark this as blocked until @ionrock can register the publisher (or grant me or @frostming the ability to do it ourselves).

[frostming]

Maybe add a pyproject.toml to explicitly specify the build backend?

https://packaging.python.org/en/latest/tutorials/packaging-projects/#creating-pyproject-toml

[woodruffw]

Maybe add a pyproject.toml to explicitly specify the build backend?

Sounds good. Want me to move the whole setup.py/setup.cfg over while I'm at it?

[frostming]

Sounds good. Want me to move the whole setup.py/setup.cfg over while I'm at it?

Sure, if the config can be read from pyproject.toml

[woodruffw]

I'll merge on top of #312, since that will probably land first.

@ionrock: I know you have limited bandwidth, but would you be able to look into configuring the trusted publisher on PyPI needed for this PR?

Here's the configuration you'll need:

• GitHub owner: psf
• GitHub repository: cachecontrol
• GitHub workflow: release.yml
• GitHub environment: none required (you can set this to release if you'd like, but please let me know if you do so I can update the workflow!)

[ionrock]

@woodruffw Done!

[ionrock]

@woodruffw I'm assuming you're going to add the release.yml as it isn't in the workflows folder.

[woodruffw]

Thanks @ionrock!

@woodruffw I'm assuming you're going to add the release.yml as it isn't in the workflows folder.

Yep, it should be included in this PR's changeset: https://github.com/psf/cachecontrol/pull/308/files#diff-87db21a973eed4fef5f32b267aa60fcee5cbdf03c67fafdc2a9b553bb0b15f34

[woodruffw]

This should be good to go whenever. @frostming, I assume we'll want to merge your 3.7 changes first.

[woodruffw]

@frostming I'll do a pre-release to test the CI here after this is merged, unless you have any objections 🙂

[frostming]

@woodruffw Go ahead, let's also update the Makefile and include a dev guide for releasing.

[frostming]

@ionrock Any chance to yank 0.13.0 to prevent users on Python 3.6 from installing this version(yeah we didn't know the context of yanking 0.12.12). We are not able to do this.

@woodruffw If the version is yanked we should be able to release this as 0.13.1

[ionrock]

@frostming Yanked!

[woodruffw]

Okay, pushed up some initial contributing docs (in the CONTRIBUTING.md style that GitHub encourages).

I've removed the old make bump target since bumpversion is unmaintained and doesn't have great support for pre-releases anyways. I'll look into other bumping tools, but for the mean time I've documented a "manual" bumping flow that's almost as simple (since I've consolidated all versions to a single file).

[frostming]

@woodruffw what about https://pypi.org/project/bumpver which should be a drop-in replacement for bumpversion

[woodruffw]

Works for me -- I'll look at adding it tomorrow.