-
In the versioning docs for actions, its encouraged that major version ‘tags’ are moved around: > Move the major version tag (v1, v2, etc.) to point to the Git ref of the current release. For more information, see “Git basics - tagging.” Generally tags should be immutible and branches are the primitive that shouldbe used on git labels that move around. It does appear major version branches work justs as well as tags, and are generally easier to manage and move around. However the docs and examples still point people in the direction of tags. Is there a reason for that? It seems like branches would serve better than tags in this case. Furthurmore, having to manage version range tags is error prone. Surea bot can do it, however common.js has already solved this problem with semver range markers. Why not just support those? Loving actions otherwise! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Thanks for the feedback. Indeed this same strategy can be accomplished with branches instead of tags, and if that aligns more with the way you want to handle release management, I don’t see any reason why you can’t. Long-term, I agree, we need to unburden you from managing semver releases yourself. We’re looking at ways to teach GitHub Actions itself about semantic versioning, instead of making you do all the work. Appreciate your thoughts on this, and we’ll work to improve this in the future. |
Beta Was this translation helpful? Give feedback.
Thanks for the feedback. Indeed this same strategy can be accomplished with branches instead of tags, and if that aligns more with the way you want to handle release management, I don’t see any reason why you can’t.
Long-term, I agree, we need to unburden you from managing semver releases yourself. We’re looking at ways to teach GitHub Actions itself about semantic versioning, instead of making you do all the work.
Appreciate your thoughts on this, and we’ll work to improve this in the future.