Bisq: Feature Request: Use git-version Gradle plugin (or equivalent) to handle version numbers

[julianknutsen]

Remove manual version number changes in favor of automatically using the commit hash and tags to identify the version. This should allow easier support when multiple versions are used internally or in the field.

Original discussion: #3707

@devinbileck
I wonder if it would be beneficial to try to implement versioning based on git commit hash? For example: https://98elements.com/blog/automatic-versioning-of-java-applications-using-git-version-gradle-plugin/

@cbeams
I'd very much like to go this route, and I actually implemented it in the (now archived) bisq-pricenode repository at one point. Have a look at bisq-network/bisq-pricenode@64f51ee, which introduces Palantir's git-version Gradle plugin, and the subsequent bisq-network/bisq-pricenode@26a0247 which reverts it. The reasons for backing that change out had to do with the hosting provider I was using for my pricenode (Heroku) not being able to support the change. I am no longer hosting there, and I believe no one else is either. If we have anyone hosting seednodes or pricenodes, etc in a Git-based push-to-deploy workflow like Heroku's, we should validate that this change won't be a problem for them, but I doubt that anyone is working that way. /cc @bisq-network/seednode-operators, @bisq-network/pricenode-operators.

[bodymindarts]

This could also be solved via more mature release process based on automated pipelines implemented in a tool like https://concourse-ci.org/.
In the risq project for example the pipeline automatically bumps the version and adds the -dev suffix after each release. https://github.com/bodymindarts/risq/commit/e64083909eb802f246d2dda4467c07bf0511fc8e

I bring it up because @cbeams has let me know of his interest in this approach. There are many advantages (that go far beyond solving this problem) though there are some initial setup costs. I'd be happy to develop the pipeline as I have a lot of experience with it but I think there needs to be a broader discussion to achieve consensus on wether or not to take that approach.

[cbeams]

Thanks @julianknutsen for submitting this.

@bodymindarts the move to Git-based versioning should be relatively simple (I took a quick look yesterday at what it would entail, and I don't think there's anything too big and hairy). Concourse pipelines may indeed be of interest, but I'd prefer to have Git metadata drive our process on the versioning side (I believe you would too, so hopefully just concurring here).