ximion
commented
1 year ago I don't think it makes much sense to change release processes for a project that is in deep maintenance mode and will likely only get few bugfix releases.
For your processes, what do you do for projects that aren't on GitHub? Maybe you want a tool like Debian'r uscan: https://manpages.debian.org/unstable/devscripts/uscan.1.en.html
Or you could hook into release-monitoring, which is an incredibly powerful tool too: https://release-monitoring.org/ (appstream-glib is https://release-monitoring.org/project/14018/ )
On create github release entry is created email notification to those whom have set in your repo the web UI Watch->Releases. gh release can contain additional comments (li changelog) or additional assets like release tar balls (by default it contains only assets from git tag) however all those part are not obligatory. In simplest variant gh release can be empty because subiekt of the sent email contains git tag name.
I'm asking because my automation process uses those email notifications by trying to make preliminary automated upgrades of building packages, which allows saving some time on maintaining packaging procedures. Probably other people may be interested to be instantly informed about release new version as well.
Documentation and examples of generate gh releases: https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository https://cli.github.com/manual/gh_release_upload/ https://github.com/marketplace/actions/github-release https://pgjones.dev/blog/trusted-plublishing-2023/ https://github.com/jbms/sphinx-immaterial/issues/281#issuecomment-1700933026 tox target to publish on pypi and make gh release https://github.com/jaraco/skeleton/blob/928e9a86d61d3a660948bcba7689f90216cc8243/tox.ini#L42-L58