Conversation
This is what I've actually been doing, but better to document it.
|
cc @AA-Turner since I think you wrote the current version of these instructions |
hauntsaninja
left a comment
There was a problem hiding this comment.
Looks good, feel free to merge or wait for AA-Turner :-)
| - Ensure that GitHub Actions reports no errors. | ||
|
|
||
| - Update the version number in `pyproject.toml`. | ||
| - Update the version number in `typing_extensions/pyproject.toml` and in |
There was a problem hiding this comment.
nit: for releases I personally find it helpful to split up steps as much as possible and not use and
There was a problem hiding this comment.
I think here it is fine as the step is "update the version number", there are just two places to do it.
A
| - `rm -rf dist/` | ||
| - `python -m build .` | ||
|
|
||
| - Install the built distributions locally and test (if you were using `tox`, you already |
There was a problem hiding this comment.
Might be nice to write out the commands for testing local builds
There was a problem hiding this comment.
I tend to just install it and import it... I'd rather leave this out for now in the hope that we'll switch to fully automatic releases.
|
I think this is fine for better release instructions. I've started to prefer release automation -- either fully automated release on PR merge, or automatic release on pushing a tag. If there would be interest in this I could mock up a GHA script? A |
|
Thanks for the reviews! I'd also prefer automatic releases, since I don't exactly trust myself to do it right. (It's a lot easier with |
The idea is entirely stolen from Hypothesis, although that project may have stolen it from somewhere else. The precis is that each PR includes a changelog fragment file ( The versioning information comes from the marker file -- either a line with release level, or release level in the suffix ( I have an implementation for another project that I'm happy to adapt for here -- the issue is testing, really, as you don't want to be releasing thousands of versions whilst tweaking the infrastructure. Test PyPI might be a good solution for this, though. A |
This is what I've actually been doing, but better to document it.