The next time you want to release a new version, simply push a git tag of the new version. It must be of format vN.N.N (And it does have to be all three point versions, unlike your first release tag.)
That will trigger this workflow. It does these steps:
Generates a changelog from the previous tag, based on git history
Creates a new GitHub release draft (for you to manually review and publish), with the changelog in the the description
Builds MacOS X (Intel) and Linux (x86_64) builds, ZIPs them up with license and readme
Attaches the ZIP files to the release as assets
If you see the draft release but no builds attached, and the master branch was indeed passing, just wait 5 minutes and try again. Due to action dependencies, the job creates the draft release first, then starts on the binary builds.
The next step of #2.
The next time you want to release a new version, simply push a git tag of the new version. It must be of format
vN.N.N(And it does have to be all three point versions, unlike your first release tag.)That will trigger this workflow. It does these steps:
If you see the draft release but no builds attached, and the master branch was indeed passing, just wait 5 minutes and try again. Due to action dependencies, the job creates the draft release first, then starts on the binary builds.
You can see an example workflow run here.