Currently, this repository does not have a formal release process whatsoever. This was mainly due to the interdepencies of various composite actions on their siblings making it complex to correctly reference the correct tag.
With this proposal, I am recommending an automated release process based on CHANGELOG versioning as was built out recently, but with added tags for the major, minor, and latest version tags generated from the full semver tag (a.k.a v1.2.3 would release tags for latest, v1, v1.2, and v1.2.3).
To get around the aforementioned problem of interdependent composite actions references, I propose a process in which the main branch is somehow manipulated to update all references to lockerstock/github-actions/*@main to instead point at the respective tag. I don't really want to muddy the main branch with a bunch of extra commits just for tagging purposes, so a release/ branching strategy might be a good idea.
Additionally, I expect the latest, major, and minor tags to always overwrite the previous tag of same name when released.
As for the CHANGELOG itself, I think a backfilled one from the PR titles would suffice for an initial version.
Currently, this repository does not have a formal release process whatsoever. This was mainly due to the interdepencies of various composite actions on their siblings making it complex to correctly reference the correct tag.
With this proposal, I am recommending an automated release process based on CHANGELOG versioning as was built out recently, but with added tags for the major, minor, and latest version tags generated from the full semver tag (a.k.a v1.2.3 would release tags for
latest,v1,v1.2, andv1.2.3).To get around the aforementioned problem of interdependent composite actions references, I propose a process in which the main branch is somehow manipulated to update all references to
lockerstock/github-actions/*@mainto instead point at the respective tag. I don't really want to muddy the main branch with a bunch of extra commits just for tagging purposes, so a release/ branching strategy might be a good idea.Additionally, I expect the latest, major, and minor tags to always overwrite the previous tag of same name when released.
As for the CHANGELOG itself, I think a backfilled one from the PR titles would suffice for an initial version.