Relases and versions - for downstream packaging?

Hi.

Saw a video from this project, https://www.youtube.com/watch?v=U3E-sWo2H_M — which talks about a release.
However, I cannot find any releases in the traditional sense other than a static [latest-stable](http://github.com/GraphiteEditor/Graphite/releases/tag/latest-stable) which was created 2022, but is updated/deleted/renewed (whatever you want to call it) every now and then?

This makes for a weird versioning and packaging scenario. I'm a package maintain for a Linux distribution, and I was curious about packaging this application — but it's hard when there's not a proper release with release artifacts that we can verify against.

Would it at all be possible, to create a proper github release for new releases, which would create release artifacts (`.tar.gz`) of the tagged commit, as well as a maintainer of Graphite to sign said release artifact?

This would help us tremendously in our work of verifying that releases come from those who say they release the software, as well as a known state (other than a commit hash).

Start by reviewing the current `latest-stable` tag and the repository's existing release setup. Define how a proper GitHub release should produce verifiable `.tar.gz` artifacts from a tagged commit and how a Graphite maintainer would sign them; done means downstream packagers can identify and verify a stable release.

Written by the indexing model from the issue text.