Do publish release version under "Releases" on GitHub for each tagged version

[Hedda]

Please consider doing releases on GiHub as well for each version instead of just only having tags for versions:

https://github.com/VCTLabs/cp210x-program/releases

https://github.com/VCTLabs/cp210x-program/tags

Some third-party integrations depend on there being release versions available under releases on GiHub.

An example of a such third-party integration is PyPI ( https://pypi.org/ ) as mentioned in #15

[Hedda]

So for each tag that represent a version like 0.1, 0.2, 0.3, etc. you also want to do a release on GitHub with same version.

Releases on GitHub are still based on Git tags:

https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases

https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository

https://stackoverflow.com/questions/18506508/whats-the-difference-between-tag-and-release

https://stackoverflow.com/questions/9810050/why-should-i-use-tags-vs-release-beta-branches-for-versioning/9810336

https://github.blog/2013-07-02-release-your-software/

[sarnold]

First, thanks for your contributions; there is now a teensy bit of CI automation, including a Github release workflow for new tags.

But, I'm not sure how much value there is in (re)tagging the older release versions, since there are several Python version related issues. That said, the "latest" release has been cleaned up quite a bit, thanks to several recent PRs, but there are still some latent issues, such as:

• the .ini config handling is slightly mangled
• the baudrate table has duplicate baudrate and whitespace issues

What seems to work:

• hex file I/O looks good

Other than the above, it's still completely untested on the legacy parts in its current state. I don't have any legacy 2101/2102/2103 parts, but I did pick up the Adafruit rpi UART board => cp2102N which basically needs a complete rewrite of the tool.