feat: Set client version for non-release binaries and version in guix based on git tags

[UdjinM6]

Issue being fixed or feature implemented

Client version string is inconsistent. Building v20.0.0-beta.8 tag locally produces binaries that report v20.0.0-beta.8 version but binaries built in guix would report v20.0.0rc1-g3e732a952226a20505f907e4fd9b3fdbb14ea5ee instead. Building any commit after v20.0.0-beta.8 locally would result in versions like v20.0.0rc1-8c94153d2497 which is close but it's still yet another format. And both versions with rc1 in their names are confusing cause you'd expect them to mention beta.8 instead maybe (or is it just me? :D ).

What was done?

Change it so that the version string would look like this:
on tag: v20.0.0-beta.8-dev or v20.0.0-beta.8-gitarc v20.0.0-beta.8
post-tag: v20.0.0-beta.8-1-gb837e08164-gitarc v20.0.0-beta.8-1-gb837e08164

post-tag format is
recent tag-commits since that tag-g+12 chars of commit hash-dirty (optional) -dev or gitarc

dev/gitarc suffixes should help avoiding confusion with the release versions and they also indicate the way non-release binaries were built.

Note that release binaries do not use any of this, they still use PACKAGE_VERSION from configure like before.

Also, CLIENT_VERSION_RC is no longer used in this setup so it was removed.

Few things aren't clear to me yet:

1. Version bump in configure.ac no longer affects the reported version (unless it's an actual release). Are there any downsides I might be missing?
2. Which tag should we use on develop once we bump version in configure? v21.0.0-init? v21.0.0-alpha1?
3. How is it going to behave once merge master back into develop kind of PR is merged? E.g. say develop branch is on v21.0.0-alpha1 tag and we merge v20.1.0 from master back into it. Will this bring v20.1.0 release tag into develop? Will it become the one that will be used from that moment? If so we will probably need another tag on develop every time such PR is merged e.g. v21.0.0-alpha2 (or whatever the next number is).

Don't think these are blockers but would like to hear thoughts from others.

How Has This Been Tested?

Built binaries locally, built them using guix at a specific tag and at some commit on top of it.

Breaking Changes

n/a

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have made corresponding changes to the documentation
• I have assigned this pull request to a milestone (for repository code-owners and collaborators only)

[PastaPastaPasta]

I don't understand the dev / gitarc postfixes

[UdjinM6]

Basically, when you clone the repo and build binaries it's share/genbuild.sh that is used to create src/obj/build.h in which BUILD_GIT_DESCRIPTION is defined. When you build it via guix (or gitian, or any other build system/script that uses git archive) it's git archive in contrib/guix/libexec/build.sh and a magical $Format:%n#define ARCHIVE_GIT_DESCRIPTION "%(describe:abbrev=12)"$ string in src/clientversion.cpp that defines ARCHIVE_GIT_DESCRIPTION (and BUILD_GIT_DESCRIPTION is not defined). So dev/gitarc suffixes simply indicate the way it was built.

Also, if you tag and try to build release binaries but forget to set _CLIENT_VERSION_IS_RELEASE to true you'll see these suffixes too.

If you don't like their names, I'm open for suggestions :)

[PastaPastaPasta]

But what circumstances will result in dev / gitarc? When will that suffix be present?

[UdjinM6]

release binaries: no suffixes

non-release binaries:

• built in a cloned repo: dev
• built in a folder extracted from git archive: gitarc

[PastaPastaPasta]

When you say "non-release binaries" do you mean building from any commit that doesn't have a tag directly on it?

[github-actions]

This pull request has conflicts, please rebase.

[UdjinM6]

I mean binaries with _CLIENT_VERSION_IS_RELEASE set to false

[UdjinM6]

rebased to fix merge conflicts after rc bump (#5656), no other changes

[PastaPastaPasta]

But in that case wouldn't building v20.0.0-beta.8 result in being shown v20.0.0-beta.8-dev?

[UdjinM6]

But in that case wouldn't building v20.0.0-beta.8 result in being shown v20.0.0-beta.8-dev?

Ah, right, I missed this in my PR description 🙈 (fixed). My initial idea was to make it show the tag only but then I realized that it would be possible to unintentionally create non-release binaries that would report the same version release binaries do so I added suffixes. It's a nice safety belt imo but if that's not needed I can drop them, np.

[knst]

is git describe --abbrev=12 produce same output on different platform/copies of repo/etc?

This string should be reproducable at any system/git status because it is included in binaries.
If it is not true, this issue will revive with new face: #5222

[UdjinM6]

It should be identical (assuming 12 digits is enough)

--abbrev=
Instead of using the default number of hexadecimal digits (which will vary according to the number of objects in the repository with a default of 7) of the abbreviated object name, use digits, or as many digits as needed to form a unique object name. An of 0 will suppress long format, only showing the closest tag.

https://www.git-scm.com/docs/git-describe#Documentation/git-describe.txt---abbrevltngt

[github-actions]

This pull request has conflicts, please rebase.

[UdjinM6]

• added f26c36e and fixed PR description as @PastaPastaPasta requested
• rebased from GH GUI to fix Merge Fast-Forward Only check

[knst]

LGTM

[knst]

nit: IMO ok to have it here

[PastaPastaPasta]

CLIENT_VERSION_RC was dropped

[PastaPastaPasta]

dropping the RC here? Ah, rc is purely based on tag now

[PastaPastaPasta]

I don't think this is working as intended with a tag at head

          ...bind-mounted in container to: '/distsrc-base/distsrc-20.0.0-7-g15ba58fbd6cc-x86_64-linux-gnu'

building from

15ba58fbd6 (HEAD -> feat_tagged_version, tag: v20.0.0-nightly-test) fix: drop `dev` and `gitarc` suffixes

[PastaPastaPasta]

Even with a more normal looking tag this is problematic

pasta@pasta1:~/guix/dash$ HOSTS="x86_64-linux-gnu" ./contrib/guix/guix-build
Checking that we can connect to the guix-daemon...

Hint: If this hangs, you may want to try turning your guix-daemon off and on
      again.

make: Entering directory '/mnt/volume_tor1_01/guix/dash/depends'
make[1]: Entering directory '/mnt/volume_tor1_01/guix/dash/depends'
make[1]: Leaving directory '/mnt/volume_tor1_01/guix/dash/depends'
make: Leaving directory '/mnt/volume_tor1_01/guix/dash/depends'
INFO: Building 20.0.0-7-g15ba58fbd6cc for platform triple x86_64-linux-gnu:
      ...using reference timestamp: 1700142908
      ...running at most 8 jobs
      ...from worktree directory: '/home/pasta/guix/dash'
          ...bind-mounted in container to: '/dash'
      ...in build directory: '/home/pasta/guix/dash/guix-build-20.0.0-7-g15ba58fbd6cc/distsrc-20.0.0-7-g15ba58fbd6cc-x86_64-linux-gnu'
          ...bind-mounted in container to: '/distsrc-base/distsrc-20.0.0-7-g15ba58fbd6cc-x86_64-linux-gnu'
      ...outputting in: '/home/pasta/guix/dash/guix-build-20.0.0-7-g15ba58fbd6cc/output/x86_64-linux-gnu'
          ...bind-mounted in container to: '/outdir-base/x86_64-linux-gnu'
^C** INT received while building x86_64-linux-gnu, you may want to clean up the relevant
   work directories (e.g. distsrc-*) before rebuilding

Hint: To blow everything away, you may want to use:

  $ ./contrib/guix/guix-clean

Specifically, this will remove all files without an entry in the index,
excluding the SDK directory, the depends download cache, the depends built
packages cache, the garbage collector roots for Guix environments, and the
output directory.
pasta@pasta1:~/guix/dash$ git log --oneline
15ba58fbd6 (HEAD, tag: v20.1.99, tag: v20.0.0-nightly-test, feat_tagged_version) fix: drop `dev` and `gitarc` suffixes
948c8f6e8d (tag: v20.0.0-btest-nightly) feat: Set version in guix based on git tags only
33c68f4f61 feat: Set client version based on git tags when building non-release version
25e5ce6c9a docs: update dmg format (#5703)
4c0c3cc1b5 Merge pull request #5704 from UdjinM6/merge_master_20.0.0
3d5ab37f9b Merge branch 'master' into merge_master_20.0.0
4dff2e0631 chore: bump version to v20.1.0 non-release (#5696)
df79078a2e (tag: v20.0.0, origin/master, origin/HEAD) chore: set release version to true; set rc to 0 (#5695)
3be7979c04 docs: add v20.0.0 release notes, archive v19.3.0 and drop partial ones (#5674)

[PastaPastaPasta]

Ahh; I must do git tag v20.1.99 -m "v20.1.99" instead of simply git tag v20.1.99

[github-actions]

This pull request has conflicts, please rebase.

[PastaPastaPasta]

Guix Automation has began to build this PR tagged as v20.1.0-devpr5653.d0b3e250. A new comment will be made when the image is pushed.

[PastaPastaPasta]

Guix Automation has completed; a release should be present here: https://github.com/dashpay/dash-dev-branches/releases/tag/v20.1.0-devpr5653.d0b3e250. The image should be on dockerhub soon.

[UdjinM6]

9345c0cd9ae71f3628a79ff8efa0d12fd7b973aa9b043dcd5674f8131aa93fd6  aarch64-linux-gnu/dashcore-20.0.2-266-gd0b3e2509224-aarch64-linux-gnu-debug.tar.gz
e988ddd10a086e68b375e3c3268efe803eb10e81affef9a0c428fd8dca7a5f3a  aarch64-linux-gnu/dashcore-20.0.2-266-gd0b3e2509224-aarch64-linux-gnu.tar.gz
2f49debf919327b718c92bb95994728af2d90dc2d3b4b4ad0162d1ecad1770c5  arm-linux-gnueabihf/dashcore-20.0.2-266-gd0b3e2509224-arm-linux-gnueabihf-debug.tar.gz
87bb75fb73689abdd55458e01fd993f7f820d9643678fbcc811e59e4a4beef65  arm-linux-gnueabihf/dashcore-20.0.2-266-gd0b3e2509224-arm-linux-gnueabihf.tar.gz
549634cb740b38bbcb86d23fcd9a97b80226de199b64318437a5ba7af5b9e544  arm64-apple-darwin/dashcore-20.0.2-266-gd0b3e2509224-arm64-apple-darwin-debug.tar.gz
fa4f99989c12cd4e814345a072cc08e8af7549cbef7aea0c6901984fc6425dd5  arm64-apple-darwin/dashcore-20.0.2-266-gd0b3e2509224-arm64-apple-darwin-unsigned.dmg
60c5ebebafd89f99a1a437e322a6ca116fc401ff392ecb899f58126f684d6b6d  arm64-apple-darwin/dashcore-20.0.2-266-gd0b3e2509224-arm64-apple-darwin-unsigned.tar.gz
0a52a7d543217b382240b3cae607e9b36f1c498748e2f8355ba23358a9f39bf8  arm64-apple-darwin/dashcore-20.0.2-266-gd0b3e2509224-arm64-apple-darwin.tar.gz
6921cc68a2c168173a446d56d2ffdab836b825240e8498acc13ef1b97fc7efb0  dist-archive/dashcore-20.0.2-266-gd0b3e2509224.tar.gz
3a87e4a5c5a01d3ac5574cf636783b8a6353fe2f0b288ce306dcf48f8508741c  riscv64-linux-gnu/dashcore-20.0.2-266-gd0b3e2509224-riscv64-linux-gnu-debug.tar.gz
7739172d5017e42ae795c09bc0b43892e124b98209cb5d8ada9a43229ed7a901  riscv64-linux-gnu/dashcore-20.0.2-266-gd0b3e2509224-riscv64-linux-gnu.tar.gz
cfa554f2042bf2e5866915e75aea68f9584fdeee36e4c3935f1c4bebc7b9fd36  x86_64-apple-darwin/dashcore-20.0.2-266-gd0b3e2509224-x86_64-apple-darwin-debug.tar.gz
b1d86b9e993d74e69eb865b58ba7b711c867c5c04d8497b75ba2ee924c5d3856  x86_64-apple-darwin/dashcore-20.0.2-266-gd0b3e2509224-x86_64-apple-darwin-unsigned.dmg
9388b9c45000a4110d954f00ca587e99b3cd0dbe593d9cb2f9206803d5804d5f  x86_64-apple-darwin/dashcore-20.0.2-266-gd0b3e2509224-x86_64-apple-darwin-unsigned.tar.gz
53af2f74f0665c2fa8c1c0510e87c3792e243898920d41a7038660c4a40f7069  x86_64-apple-darwin/dashcore-20.0.2-266-gd0b3e2509224-x86_64-apple-darwin.tar.gz
7f80a713795a12e7cf1e73e45088e5d17906e869e3c0b0bb8faf1e6afe277af2  x86_64-linux-gnu/dashcore-20.0.2-266-gd0b3e2509224-x86_64-linux-gnu-debug.tar.gz
3993ae95c394b1da9fec61cb0bf4610e827cc12b0a6a974cd39377406502516f  x86_64-linux-gnu/dashcore-20.0.2-266-gd0b3e2509224-x86_64-linux-gnu.tar.gz
c3420e129c35597ccafee00eb8869b2400523c2dae7261588c483b20328991dc  x86_64-w64-mingw32/dashcore-20.0.2-266-gd0b3e2509224-win64-debug.zip
0ca985b4e8cdd90b65566a32869c42b3847d5765198863289cd5f5ae07769975  x86_64-w64-mingw32/dashcore-20.0.2-266-gd0b3e2509224-win64-setup-unsigned.exe
e1bc041dbbe67a2c4a1eedb7671da515c7c311a6007f34e6e6a5004748a77370  x86_64-w64-mingw32/dashcore-20.0.2-266-gd0b3e2509224-win64-unsigned.tar.gz
8e6fa1f2c38a3e9c84d423a647c541cb684d3a7168f94caeb1e475d6c5d7568f  x86_64-w64-mingw32/dashcore-20.0.2-266-gd0b3e2509224-win64.zip

[UdjinM6]

Oh wait... GitHub guix build failed... please investigate?

Good catch! Should be working now.

[PastaPastaPasta]

utACK for squash merge; I'm a little concerned about ability to have multiple tags on one commit; but I guess we can just push a new empty commit to push a new tag

[PastaPastaPasta]

utACK for squash merge; I'm a little concerned about ability to have multiple tags on one commit; but I guess we can just push a new empty commit to push a new tag

I think even in this case with two tags on the same commit it should work as expected; ie the later tag gets priority; tested via

> $ git tag v20.0.3-test -m "v20.0.3-test"                                                                                          [±develop ●]
                                                                                                                                                 
> $ git describe --abbrev=12 --dirty                                                                                                [±develop ●]
v20.0.3-test
                                                                                                                                                 
> $ git tag v20.0.3-test2 -m "v20.0.3-test2"                                                                                        [±develop ●]
                                                                                                                                                 
> $ git describe --abbrev=12 --dirty                                                                                                [±develop ●]
v20.0.3-test2

[knst]

LGTM didn't test though