Configure GitHub actions to publish packages

[acdha]

This is a first pass enabling the PyPI trusted publisher workflow

[acdha]

@cclauss I wanted to make it easy for you to run releases for these projects & figured I'd start with pysolr since it's simpler than Haystack. Beyond the obvious “does this actually work” check, one thought I had is reviewing the branching model. I'd been meaning to get away from “master” for a while and was wondering whether we should have “development” and “release” to make it more clear which one tracks the releases you get on PyPI which is more work in progress.

[cclauss]

I think it is better to keep a default master/main branch that is up-to-date. Then make release branches (named like v3.9.0) for each release. This way when folks want to make contributions, they make them to the default branch but if other folks want the code for a particular branch, it is also available to them. Thoughts?

[acdha]

I think it is better to keep a default master/main branch that is up-to-date. Then make release branches (named like v3.9.0) for each release. This way when folks want to make contributions, they make them to the default branch but if other folks want the code for a particular branch, it is also available to them. Thoughts?

I'd probably only create a branch if we actually were working on something big and upgrade-blocking, such as adding async support or something like that. In general we've tended to encourage people to fix problems by installing the latest version so maybe we should:

1. Rename “master” to “release”
2. Update the readme to note that changes against an old release which can't be made against the current release branch should use a versioned branch along the lines of v3.x, etc.

[cclauss]

"Release" is not a self-documenting branch name in my book but let's go for it.