Use GitHub Releases

[davidgilbertson]

What's the problem this feature will solve?

For each tool that I use, I 'watch' that tool in GitHub which gives me a handy notification anytime there's a new release.

pip seems to be the odd one out in using GitHub but not doing releases on GitHub.

Describe the solution you'd like

Consider doing releases on GitHub. There are ways to do this and have it on the website too.

Alternative Solutions

Some folks (like NumPy) have all the release details in the GitHub release, and also on their site.

Others (like Pandas) just put a quick note in GitHub with a link to their releases page.

Additional context

Clearly this is a pretty minor thing, but would be nice!

Code of Conduct

• [X] I agree to follow the PSF Code of Conduct.

[uranusjr]

The release procedure is mostly automated, and I would welcome a contribution adding GitHub Releases after a tagged version is uploaded in Git.

https://pip.pypa.io/en/stable/development/release-process/#id5

[davidgilbertson]

So, the low-tech option might be an extra step in that process. It could possibly be as streamlined as a link to click, and the releaser picks the tag, types a name, and uses the auto-generated release notes as described here: https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes. That's probably < 10 seconds once you've done it a few times.

Slightly more advanced option would be to configure a .github/release.yml file to fine tune the auto-generated release notes.

More advanced still option would be to have something (the upload-release step?) use the GitHub API to create a release.

And in any case you might want to either do all the old releases, or just a special "Before 23.2" release pointing to the docs.

[pfmoore]

So, the low-tech option might be an extra step in that process.

I really don't want to add an extra manual step to the release process. I'm very good at forgetting details of what I need to do in a release, and more complexity (even if you characterise it as relatively simple) doesn't appeal to me.

I think that if we're going to do this, it needs to be an additional (non-interactive) step in nox -s upload-release (because we would, I assume, want to do the PyPI and github releases in sync).

Also, looking at NumPy and Pandas (that you mentioned) they put the changelog entry in the release. That suggests to me that there might be an expectation of at least that level of detail. Do we know if towncrier can generate a suitable release note along with our existing changelog file? If not, how would we create that? No, don't suggest "cut and paste from the changelog"!

I'm not objecting to this being added, I just don't want it to be extra work for the RM, or the source of ongoing maintenance requests.

And in any case you might want to either do all the old releases

Nope. IMO, if we do this, it starts at release X, and older releases simply aren't on github.

[pradyunsg]

And in any case you might want to either do all the old releases

Nope. IMO, if we do this, it starts at release X, and older releases simply aren't on github.

FWIW, I'm not as opposed to the suggestion of backfilling things TBH. It's fairly straightforward to do that using our existing git tags.

More advanced still option would be to have something (the upload-release step?) use the GitHub API to create a release.

IMO, that's likely the best option here. :)

[sbidoul]

If we want to do this, we could also want to convert the changelog to markdown in order to facilitate uploading release notes on the GitHub release.