Pick the higher version if there are multiple on the current commit #162
Conversation
Currently, when there are multiple version tags on the current commit, one is picked semi-randomly. I say `semi` because it's actually deterministic, but it doesn't quite make sense. Anyway, if there are two tags, it typically picks the highest one, unless the last segment has more decimals (e.g. it picks `0.9` over `0.10`, and `0.99` over `0.100`). ``` git tag v0.1 git tag v0.2 sbt 'show version' #0.2 git tag v0.9 git tag v0.10 sbt 'show version' #0.9 ``` Technically you could say "who cares, it's the same commit anyway", but if you then publish the package to the jar repository, you have to pick the right one, and that's the one with the higher version - because the latter one is likely already published and it will fail on the attempt to re-publish. Note: the [sort algo](https://github.com/mpollmeier/versionsort/blob/master/src/main/java/versionsort/VersionHelper.java) is short enough to copy it (and it's tests) into this repo, if you want to save a dependency. That jar has zero dependencies though (not even scala). I use it for another project and just published it to maven central.
|
Note: the package is on sonatype and will be synchronised to maven central shortly, which will greenify travis. |
|
@dwijnand I was hoping this one's straightforward...? |
|
Restarting CI to pickup the jar. |
|
Thanks! Would be great if you could release a new version with this, we're running into this bug once a week :) |
|
I can suggest https://github.com/dwijnand/sbt-dynver, where I've got Travis CI publishing. But you'd have to resolve the same issue: sbt/sbt-dynver#48 ;-) |
|
Soooo.. any chance we can get an 1.0.1 release with this included? While we're at suggesting, this would help you to not have requests like this in the future :) |
|
I think this should be reverted. Does not work when the conflict is not on HEAD. |
|
@haavardw what's a use case for not working with HEAD? |
Currently, when there are multiple version tags on the current commit, one is picked semi-randomly. I say
semibecause it's actually deterministic, but it doesn't quite make sense. Anyway, if there are two tags, it typically picks the highest one, unless the last segment has more decimals (e.g. it picks0.9over0.10, and0.99over0.100).Technically you could say "who cares, it's the same commit anyway", but if you then publish the package to the jar repository, you have to pick the right one, and that's the one with the higher version - because the latter one is likely already published and it will fail on the attempt to re-publish.
Note: the sort algo is short enough to copy it (and it's tests) into this repo, if you want to save a dependency. That jar has zero dependencies though (not even scala). I use it for another project and just published it to maven central.