You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the release workflow is used to publish the package to typst/packages.
I propose changing it to be named publish and add a new workflow called release which actually handles the release on the repo itself.
This new workflow should either:
on push of a tag matching v*: create a new draft release, or
on creation of a release, upload release artifacts to a release page.
In either case, such an action should do a few things:
Generate a default changelog from either a CHANGELOG.md file or the main git commit history
Although GitHub can do the latter for you, so this might not be too important.
Compile and package supplementary material for a release, like manuals and other assets.
There's no hard rule on how documentation is done for Typst packages yet, most people simply compile a manual, some others like cetz host their own GitHub Pages, we could look at popular packages and adapt some of their practices.
The text was updated successfully, but these errors were encountered:
I agree that splitting publishing and releasing into separate commands would be beneficial - too many times have I botched a release and needed to manually clean up branches and tags, when it could have been averted by splitting the process
Currently, the
release
workflow is used to publish the package totypst/packages
.I propose changing it to be named
publish
and add a new workflow calledrelease
which actually handles the release on the repo itself.This new workflow should either:
v*
: create a new draft release, orIn either case, such an action should do a few things:
CHANGELOG.md
file or the main git commit historycetz
host their own GitHub Pages, we could look at popular packages and adapt some of their practices.The text was updated successfully, but these errors were encountered: