Closed etiennelndr closed 3 years ago
Hi! The sorting logic did change a bit between 1.5.0 and 1.5.1, but what you're seeing is ultimately a "feature" of Git's lightweight tags (created by git tag foo
). They don't store their own creation timestamp, so when there are multiple of them on a single commit, there's no way to determine which one was created last. If you use annotated tags (git tag foo -m "comment"
), then a tag timestamp is saved separately from the commit timestamp, which enables better sorting.
The prior behavior was kind of a happy accident and wasn't guaranteed to happen consistently. Consider what happens when you make rc1
before rc0
:
$ git init
Initialized empty Git repository in C:/tmp/d3/.git/
$ touch foo
$ git add .
$ git commit -m Initial
[master (root-commit) 804464f] Initial
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 foo
$ git tag v0.1.0-rc1
$ git tag v0.1.0-rc0
$ git tag -l
v0.1.0-rc0
v0.1.0-rc1
$ git tag --merged HEAD --sort -creatordate
v0.1.0-rc0
v0.1.0-rc1
$ dunamai from git --latest-tag
0.1.0rc0
In this case, v0.1.0-rc0
is the newest tag, so the output ends up being correct, but not because Dunamai actually knows which one was created more recently.
Description
It seems that Dunamai selects the wrong tag when multiple tags are set on the same commit. When creating two tags on the same commit (e.g.
v0.1.0-rc0
andv0.1.0-rc1
), the first one is selected and used to create the full version. Isn't it supposed to be the opposite?This behaviour may have appeared in the version 1.5.1 as version 1.5.0 selects the latest tag created by the user.
Reference
With version 1.5.1 (I have the same result with version 1.5.4):
But, with version 1.5.0 the output is different: