Better git workflow with better build and release CD pipelines

[hiro-v]

Is your feature request related to a problem? Please describe.

Recently I created a PR #158 that had been approved and merged to the main branch, even through everything went well in the PR it self, the merge commit that landed on main trigger another Github Action job to immediately Build and publish to TestPyPI and PyPI. This job then failed due when it cannot upload a wheel file with the same name to a previous deployed version. I understand that I can somehow create another PR to bump the package version so the package can be build and release properly. But I find this to be very strange:

• First of all, I don't think every commit landed on main should be build and push to PyPI immediately, that would cause many unnecessary version changes, even if we some how tag these package version using the exact date and time when the CI job was ran.
• Second, publish our package to TestPyPI, then PyPI directly next to it in the publish pipelines does not add any value. Why do we need to push the package to TestPyPI first if we don't even plan to do any test on the test package ?
• And finally, I see that we have automatic tag creation at the end of the pipeline so user can I find the source code for each h1st version release on PyPI. But what about the change logs for each version ? Where and how our user can find the changes between each h1st version easily ?

Describe the solution you'd like

Inspired from other popular Python package, I think we should change our git workflow with better build and release CD pipelines to solve this problem:

1. No longer trigger to Build and Release h1st python package on every merge to main. Instead what we should do is to only trigger this pipeline on release creation: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release
2. No longer publish our package to TestPyPI since it does not add any value
3. Utilize the Release feature of Github to track each release version, with automatic change logs, generated by commit history so our user have a central place to know which changes between each h1st version. The release creation will also trigger the build and release CD pipeline, so it will only be run when it actually needed
4. Better main merge policy, only allow squashed commit with link to the original PR so the git commit history on main will always be nice and readable, this also allow automatic change logs of Github to work very well

Describe alternatives you've considered
None

Additional context
None