version could be wrong when there are more than 1 tags on the commit

when there’s 1.9.0 and 1.10.0 as annotated tags for a commit, 1.9.0 will be returned (probably because it’s the first thing in a list thats sorted alphabetically). it should probably be sorted via semver and always return the larger version instead.

notice that this only happens because of the string “9” is greater than “1”. it’s fine on other versions

[philgebhardt]

I am running up against this issue as well. And have created https://github.com/palantir/gradle-git-version/pull/103?w=1

If I have 3 subprojects which are versioned independently, I want to ensure my projects keep track of their own versions.

subprojects {
    apply plugin: 'java'
    apply plugin: 'com.palantir.git-version'

    version gitVersion(prefix: "${project.name}-")
}

So, given the following git log:

commit 66aaf3f4d14706dfcd5ef5827638f94da29a1179 (HEAD -> master, tag: foo-0.0.1, tag: baz-0.0.2, tag: bar-0.0.1)
Author: Phil Gebhardt <[e-mail]>
Date:   Wed Aug 29 15:00:00 2018 -0700

    add project

commit 10bc56263aec8c6c8d6cf73e05b6434f778a174e (origin/master, origin/HEAD)
Author: Phil Gebhardt <[e-mail]>
Date:   Wed Aug 29 14:00:00 2018 -0700

    Initial commit
(END)

When I run printVersion for my 3 subprojects, I currently do not get the correct results:

Actual

root@9e2fc3e2a70c:/git-version# ./gradlew printVersion

> Task :services:bar:printVersion
0.0.1

> Task :services:baz:printVersion
66aaf3f

> Task :services:foo:printVersion
66aaf3f


BUILD SUCCESSFUL in 5s
3 actionable tasks: 3 executed

Expected

root@9e2fc3e2a70c:/git-version# ./gradlew printVersion

> Task :services:bar:printVersion
0.0.1

> Task :services:baz:printVersion
0.0.2

> Task :services:foo:printVersion
0.0.1


BUILD SUCCESSFUL in 6s
3 actionable tasks: 3 executed

By moving the prefix filtering logic to mapCommitsToTags, we can acheive the desired result.

[sixinli]

I have done some testing and the behaviors of JGit and ‘git describe’ are actually different: one return the first tag and one return the last, but none guarantee that it’s the latest version. So it’s actually not returning what ‘git describe --tags’ would return anyways. I think it would be more useful to support returning the latest version instead of random alph-sorted result.

Thanks, Sixin

On May 27, 2016, at 3:47 PM, Mark Elliot [e-mail] wrote:

Hm, I’m not sure we can deal with this edge case in a reasonable way. The goal of this (simple) plugin is just to produce a version string equivalent to ‘git describe --tags’. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.