What is a good version scheme including a build number?


(Ralph van Etten) #1

I would like to use the build numbers from the CI in the version number, but only for beta releases (I am open for suggestions)

I considered using semantic versioning, but from what I have found it seems Gradle does not support this. I would like to use something like 1.0.0-123, 1.0.0-124 etc. for beta releases and then the final release will be 1.0.0

What is a good versioning scheme which includes build numbers when using Gradle?


(Benjamin Muschko) #2

You can assign an instance of java.lang.Object to the property “version” using the setter method on Project. This means that you can create a custom class that contains any logic you are trying to implement. How you want to define the versioning scheme is specific to your project.


(Ralph van Etten) #3

If I invent my own versioning scheme or use semantic versioning, how will Gradle pick the right version for dependencies?

For instance, if my project depends on version 1.0.+ (or latest.integration), does gradle know version 1.0.0-123 < 1.0.0-124 < 1.0.0-125 < 1.0.1-126 < 1.1.0-300 ?


(Benjamin Muschko) #4

Good question. I never tried this out. I think it will if you use a dot instead of a dash sign in the version number e.g. 1.0.0.123.


(Luke Daley) #5

Ordering is purely lexicographical.

So you can test out how Gradle will compare them by comparing the strings in Java.


(Ralph van Etten) #6

Are you sure? The string “1.0.9” is lexographically greater than “1.0.10” which does not seem right…


(Luke Daley) #7

You’re right, I was looking in the wrong place.

The code is here: https://github.com/gradle/gradle/blob/master/subprojects/core-impl/src/main/groovy/org/gradle/api/internal/artifacts/ivyservice/ivyresolve/strategy/ExactVersionMatcher.java#L59


(Ralph van Etten) #8

Great! So if I am not mistaken it will be: “1.0.1-dev123” < “1.0.1-rc125” < “1.0.1”

That will work nicely.