Move the release GHA job into a separate workflow

[adiroiban]

The current implementation is nice, since the tests are executed first, and the release is only triggered if the tests are green.

I don't like the current implementation in which we create a tag first and then do a release.
I would prefer to do a release (final or candidate), and if the PyPI publish was successful, create a tag after the publish.

We can use this issue to discuss alternatives

[adiroiban]

Moving the discussion here

Well, it's not. :) But it deduplicates the version information to one place (we do git tags too) and enables the continuous uploads I've mentioned. But obviously, if you don't want it, it's not happening. Just wanted to offer. :)

Originally posted by @hynek in #491 (comment)

[adiroiban]

I am +1 for continuous integration / testing... but I am not sure if we should do it for towncrier.

I am doing continuous dev releases for my private project for every push to a PR... but it is pushed to a private server.

I don't know if a .devN release will be every use by someone ... and I am not sure if a .rc1 release is used by anyone.

Towncrier is a simple dev tool... and as a dev, if you need an unreleased version, you can install from git.

---

Are the guys from PyPI ok to use the server for continuous integration testing?

I read "allows you to try distribution tools and processes" and to me, it means that it's ok for developing new processing, but not for continuous testing of an existing process that you know that it works well.

I guess that if every PyPi project would start pushing version for every commit, you can end up with a high load and high invoice on this service.

---

Even though I helped with the latest releases, my goal is to have the release process a simple as possible so that any other developer can trigger a release.

---

So @hynek if you want to move the release jobs in a separate .YAML and enable VCS based releases I will not reject such a PR.

---

So I am not -1 for hatch-vcs, it's just that I am not excited about it :)

Cheers

[hynek]

Towncrier is a simple dev tool... and as a dev, if you need an unreleased version, you can install from git.

To be clear, the continuous uploading is not about distributing pre-releases, but about testing. Always being able to see how the README actually looks like or being able to download wheels etc.

---

For the bystanders: (test.)pypi.org doesn't allow to upload the same version multiple times, so a way is needed to have a unique version for every commit on trunk. That can be easily achieved with hatch-vcs which will just count up from the last tag.

OTOH it's impossible to specify the version as we'd like it, so currently it would always be 23.6.1.devX with X being the number of commits since the 23.6.0 tag.

[adiroiban]

I think that this can be closed.

What we need to do, is look into publishing to testpypi as part of a PR... but that is for another ticket