Release workflow

[JOJ0]

This implements a semi-automatic release workflkow.

It should help us to:

• Not think too much when putting out a release.
• Change versions in all relevant files.
• Create a draft of an release on github that helps us stay consistent in our release notes.
• Build and upload to PyPI.

I wrote the original versions of these scripts for https://github.com/JOJ0/synadm and have been using them for quite some time now already. We basically can assume they are tried and tested. I added some better documentation/commenting and also improved tiny things in their code here and there. So a little testing needs to be done here again. I did test everything as good as I can but please I need you @AnssiAhola and @alifhughes to do the following:

• Read release.txt to get a basic idea of what the required steps are.
• Install the required package bump2version into your venv.
• Pull this PR's branch into your fork of the repo.
• Create a testfile to have some changes.
• Use bump.sh to automatically tag HEAD with a new version.
• git push --follow-tags to trigger the release workflow.
• Check whether a new release has appeared for that tag on your github fork of the joalla repo.
• Upload the package to Test-PyPI

Something like this:

pip install bump2version
git remote add jojo https://github.com/joj0/discogs_client
git fetch
git checkout release_workflow
touch testfile1
git add testfile1
bump.sh patch
bump.sh patch doit
git push personal_remote --follow-tags
./release.sh

So the next time we would put out a real release (will be 2.3.13), the one who is doing it would do:

./bump.sh patch doit
git push --follow-tags
# Go to github and fill in release notes in the prepared release
./release.sh

So you see that we don't even have to type the version number ourselves, bump2version does that for us. Alternatively if we want to increase the middle number (.3.) we would do: ./bump.sh minor doit and get a new version v2.4.0.

Also nice: If, for some reason, a release named v2.3.13 is already existing on joalla/discogs_client, it would not be created a double but connected to the new tag v2.3.13 we are pushing!

release.sh is safe to try out as well, it builds a wheel and just uploads to Test-PyPI. The upload to Production PyPI is only suggested by printing the command that needs to be executed to do it.

[AnssiAhola]

Seemed to work fine for me.
Well... after I found the correct workspace for my fork and remembered to install bump2version to that venv as well (installed to the wrong one first) 😅
Also it seemed to add one extra white space to the .bumpversion.cfg file, probably not a problem but thought I should let you know AnssiAhola@0cfdf3a

[JOJ0]

Hi, please review my changes in the latest commit. I added a guidance script named release_workflow.sh. In the end I decided that it shouldn't execute anything by itself. Error handling would have been a lot of work to do and IMHO not easily possible at all. It just spits out what the "releasing person" has to do as a checklist. Error handling should be done by a human if you want it that way ;-)

I didn't test the steps through again but wrote it by heart. Hope I didn't forget anything. Please play it through again! There might be things that could be explained better. Tell me!

[AnssiAhola]

Sorry, forgot about this.

I tested the process again and added some comments in review.
Also I got stuck to the release.sh part again where I tried to upload to Test-PyPI and it asked for credentials. I don't think that is big deal if it works for you, might just be that I lack permission to Test-PyPi/PyPI