Bisq: [1.2.4] Wrong version number in 1.2.4 release branch

[julianknutsen]

Description

Text show v1.2.3

Version

548a21775

Steps to reproduce

• Build tip of release/v1.2.4
• Look at version string

Expected behaviour

v1.2.4

Actual behaviour

v1.2.3

Screenshots

Device or machine

N/A

Additional info

Version strings can be tricky if we have users or testers building from master and they submit bug reports. Would it make sense to only set version numbers in release branches and have the version on master be development or something like that?

[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 wonder if it would be beneficial to try to implement versioning based on git commit hash?

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.

[julianknutsen]

confirmed fixed in 5880ad99c

It would be nice to have the feature listed above. I split that into a feature request so that we can track 1.2.4 bugs separately through release. #3735