Versioning in gradle and git

[Desrever Nu]

In the output of gradle build I read

this project is version 0.20-rc1

Will it be possible to set the version to the current local branch name, similarly to what we already did?

[Benjamin Cordes]

there is currently the ability to use the git branch and commit via the .nubot file, as used in the gradle task propfile. Combined with the util function where we tell we're inside a jar or not, we can tell a) if we're in production (i.e. a jar) or in an IDE b) which branch we're on

see public static String versionName() { in Utils. There I read from the ".git" directory directly also (if we're in develop).

[Desrever Nu]

I see, but what about build.gradle?

[Benjamin Cordes]

Build.gradle creates the Jar and the ".nubot" file. In the line 254 of build.gradle this variable version gets used:

prop.put("version",project.version)

That way we have the version at runtime in the IDE and the jar. perhaps this could be written better in the manifest file of the jar? https://docs.oracle.com/javase/tutorial/deployment/jar/packageman.html.

inside the jar, the git branch is not accessible anymore, so we have to write the information somewhere.

[Desrever Nu]

What I want to achieve is automatically set the variable that currently is set manually at line 27

version = '0.20-rc1' //will be used for logging

Is that feasible?

EDIT: or delete the variable if we don't use it

[Benjamin Cordes]

It is a variable and it is used. The build.gradle is groovy code under the hood which wraps around the java code. The comment is probably unclear - it should read sth like:

version = '0.20-rc1' //this is used for logging, see line 254.

What we perhaps need are some conventions for use in git and gradle. For example: with each release candidate change the build.gradle. AFAIK there is nothing inherent in git that defines what a version is, only tags which point to a commit (and then we should change the gradle file accordingly).

For example we could re-use this if we adopt gradle-wrapper or other functionality. Perhaps this should be in the jar manifest. Another example if would have several projects, and one project reads the version number of this project.

[Desrever Nu]

For example: with each release candidate change the build.gradle

Yes, this is how this was done so far : for each new RC or stable version, I d go and manually change the version variable, and leave it "develop" in the develop branch.

Since the git branches have the same name of the versions, I was wondering if the process above could be automated to avoid having to remember to update the version.

But it is really a minor issue and if it creates overhead, no worries.

[Benjamin Cordes]

yes, manual is better in this case. every time there is a new release, the variable gets changed.

build.gradle => https://bitbucket.org/JordanLeePeershares/nubottrading/src/5ef2822d9353b2aa43347272e7e6f1142b650fe5/build.gradle?at=develop#cl-317

Utils.java => https://bitbucket.org/JordanLeePeershares/nubottrading/src/5ef2822d9353b2aa43347272e7e6f1142b650fe5/src/main/java/com/nubits/nubot/utils/Utils.java?at=develop#cl-432

[Benjamin Cordes]

just cleaned up this part of the code and put the relevant code in Utils/VersionInfo.

[Desrever Nu]

Perfect, I'll create now a release-process.md