Closed rtbs-dev closed 4 years ago
OH! apologies....I deleted all tags missing "v" from the beginning, after trying to only delete the "mistake" one that had it. Then nothing was returned by dunamais.
Now, tagging with a v
, all seems to be working correctly.
Still, it's my understanding that semver doesn't actually require the v
. Is this desired behaviour?
Hello! I made the default configuration require the v
prefix since that's the most prevalent tagging convention I've seen among open source projects. The v
isn't part of the version itself (Dunamai's output does not include it) and so isn't subject to SemVer, but it's used on the input to help avoid false positive tag matches. Since Dunamai supports other output formats than SemVer and since tags don't have to conform to the output format anyway, you might end up with a tag like simply 1
getting picked up as a version, which I wouldn't feel confident enough about. All that said, you can use --pattern
to avoid the v
prefix if you prefer.
This entry in the SemVer FAQ also references a v
prefix in tags: https://semver.org/#is-v123-a-semantic-version
Great, thanks for the clarification! I'll mark this closed since it's by-design.
For the sake of others, is there maybe a way to report when only a subset of tags are getting matched? Before deleting the single tag having a v
prefix, dunamai happily chugged along only returning that one. I only figured out the issue after deleting that tag, which returned the fuii list of "false negatives":
$ dunamai from git
Pattern '^v(?P<base>\d+\.\d+\.\d+)(-?((?P<stage>[a-zA-Z]+)\.?(?P<revision>\d+)?))?$' did not match any tags from ['0.1.4', '0.1.3', '0.1.2', '0.1.1']
Since this is human error, and ostensibly our intention under dynamic versioning is to match all of the tags (which dunamai has access to a priori), couid a debug flag be added that reports tag subsets that failed to match the given pattern?
Good idea; I'll look into adding something like that. I could imagine having some output on stderr like:
Matched tag: v0.1.1
Newer unmatched tags: 0.1.4, 0.1.3, 0.1.2
Found this super useful tool via
poetry-dynamic-versioning
.However, after working the first time, subsequent builds failed to add the patch version, instead adding revisions to my first patch.
git describe --tags
returns0.1.4
, but runningdunamai from git
returns0.1.1.post8.dev0+9838662f09
. Did some digging and the command I found here returns these tags:Is that the right order? This answer seems to use the same/similar syntax, but in reverse order.