Trask Stalnaker

I updated the workflow to work with "pre-release" versions, e.g. "1.13.0rc", and tested making a "pre-release" in https://github.com/trask/repository-template/releases/tag/v1.1.0rc. I'll re-test the full workflow in my `opentelemetry-python` fork one last time...

oops! didn't mean to delete _that_ branch 😅 I made some nice simplifications to the change log management based on conversations above. I'm re-testing all the workflows on my fork...

I tested the release workflow in my fork for the next release, which I understand will be 1.12.0rc2/0.32b0 (it could also be 0.31b1, but it makes the release workflow cleaner...

ok, I've re-tested all the workflows on my otel-python fork, I think this is ready for a final review

> For the two PRs that are generated from `prepare-release-branch` workflow, for the second pr that updates the version in main from `1.12.0rc2-dev` to `1.12.0-dev`, is this expected? I'm not...

> And if you don't want to mess with -dev that's not a problem, I can remove that. I assume in that case you'd want the version in main to...

I kept the `-dev` suffix for now, but improved the prerelease ("release candidate") handling: * renamed "prerelease" in the workflow to "unstable", I think this is a clearer distinction between...

I will do another full test of the workflows on my fork, but will wait a bit to see if you would like any other behavioral changes first

I switched the order to publish to PyPI before publishing the GitHub release. This is what we've done in Java, since publishing to Maven is more likely to fail, but...

> It is a python specific thing: https://peps.python.org/pep-0440/#pre-releases nice, thx for sharing the link 👍 > I think adding `dev` is a decision made by the Python SIG because we...