Closed alvasw closed 2 months ago
@HenrikJannsen Are there any other files I forgot to cover?
Found it also in gradle.properties
: version=2.0.0
@alvasw Whats the easiest way for gradle scripts to read in the version number? Would a text file version
with only the version string in it be good? Or better a property file?
For the config we could read in that file at startup and remove it from the config files.
We would though apply one global version to all applications (e.g. if no changes happened in oracle it still would get a new version number).
@alvasw Happy to tackle this one. My approach would be to leave the application version definition ONLY on gradle.properties
and then using gradle task and a new static class link it to the java world and make it globally accessible updating all the current usages.
started work on this one first
@alvasw @HenrikJannsen hey guys! have a look at this when you have a moment! :)
https://github.com/bisq-network/bisq2/pull/2526
I think we could get rid of version.txt (at least in common) and its usages but we can always do it in a cleanup PR, let me know your thoughts, cheers!
I believe this one can be closed now :)
We set the Bisq version in many places:
desktop.conf
,oracle_node.conf
,rest-api.conf
, andseed_node.conf
Release Managers must update the version number in all of these files. We could provide an bump version number script (like in Bisq 1) for now. I'd recommend to set the version globally and pass is to all sub-modules long-term.
Relates to #1764.