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
I have marked this as a general idea because I am not 100% certain on the implementation of semver in the use case as follows.
Problem
As a software dev I am are looking to implement unique tag names between git commits and branches to support immutable container tags. There are a lot of reasons for that I don't think are useful to get into. So let's assume its a requirement. I believe git-semver can already do but only through using existing tags in git. Which in some cases might make CI pipelines logic a bit more complex then if I could use the branch name as the prerelease.
So something like: vx.y.z-branch.commits+sha
How git-semver does it
git-semver already supports this sort of format but with an an additional identifier .dev.. It can be done by tagging the first commit of your branch with the release version and prerelease name (e.g. git tag v0.16.2-rc SOMESHA . Examples of versions after creating such a tag could be:
I find the above versions verbose over something without the additional .dev., in addition having to create the tag in git before hand can make some workflows a bit cumbersome.
If git-semver had another flag like --set-prerelease that took a string that set the prerelease section when running it would eliminate the need to have a git tag before running the tool and still allow a more identifiable release.
Example behavior
With a git repo with the latest tag being v0.16.1 and having checked out a feature branch psql-to-parade with two commits already on it you could run something like:
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I have marked this as a general idea because I am not 100% certain on the implementation of semver in the use case as follows.
Problem
As a software dev I am are looking to implement unique tag names between git commits and branches to support immutable container tags. There are a lot of reasons for that I don't think are useful to get into. So let's assume its a requirement. I believe
git-semvercan already do but only through using existing tags in git. Which in some cases might make CI pipelines logic a bit more complex then if I could use the branch name as the prerelease.So something like:
vx.y.z-branch.commits+shaHow
git-semverdoes itgit-semver already supports this sort of format but with an an additional identifier
.dev.. It can be done by tagging the first commit of your branch with the release version and prerelease name (e.g.git tag v0.16.2-rc SOMESHA. Examples of versions after creating such a tag could be:v0.16.2-rc.dev.17+3bc320a9v0.16.2-alpha.dev.17+3bc320a9v0.16.2-specialfeature.dev.17+3bc320a9v0.16.2-branch-name.dev.17+3bc320a9Desired Behavior
I find the above versions verbose over something without the additional
.dev., in addition having to create the tag in git before hand can make some workflows a bit cumbersome.If git-semver had another flag like
--set-prereleasethat took a string that set the prerelease section when running it would eliminate the need to have a git tag before running the tool and still allow a more identifiable release.Example behavior
With a git repo with the latest tag being
v0.16.1and having checked out a feature branchpsql-to-paradewith two commits already on it you could run something like:Beta Was this translation helpful? Give feedback.
All reactions