mirror of
https://github.com/dashpay/dash.git
synced 2024-12-25 20:12:57 +01:00
f72650d2de
## 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: - [x] I have performed a self-review of my own code - [x] 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 - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_
40 lines
1.1 KiB
Bash
Executable File
40 lines
1.1 KiB
Bash
Executable File
#!/bin/sh
|
|
# Copyright (c) 2012-2019 The Bitcoin Core developers
|
|
# Distributed under the MIT software license, see the accompanying
|
|
# file COPYING or http://www.opensource.org/licenses/mit-license.php.
|
|
|
|
export LC_ALL=C
|
|
if [ $# -gt 1 ]; then
|
|
cd "$2" || exit 1
|
|
fi
|
|
if [ $# -gt 0 ]; then
|
|
FILE="$1"
|
|
shift
|
|
if [ -f "$FILE" ]; then
|
|
INFO="$(head -n 1 "$FILE")"
|
|
fi
|
|
else
|
|
echo "Usage: $0 <filename> <srcroot>"
|
|
exit 1
|
|
fi
|
|
|
|
GIT_DESCRIPTION=""
|
|
if [ "${BITCOIN_GENBUILD_NO_GIT}" != "1" ] && [ -e "$(command -v git)" ] && [ "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = "true" ]; then
|
|
# clean 'dirty' status of touched files that haven't been modified
|
|
git diff >/dev/null 2>/dev/null
|
|
|
|
# override using the tag name from git, i.e. string like "v20.0.0-beta.8-5-g99786590df6f-dirty"
|
|
GIT_DESCRIPTION=$(git describe --abbrev=12 --dirty 2>/dev/null)
|
|
fi
|
|
|
|
if [ -n "$GIT_DESCRIPTION" ]; then
|
|
NEWINFO="#define BUILD_GIT_DESCRIPTION \"$GIT_DESCRIPTION\""
|
|
else
|
|
NEWINFO="// No build information available"
|
|
fi
|
|
|
|
# only update build.h if necessary
|
|
if [ "$INFO" != "$NEWINFO" ]; then
|
|
echo "$NEWINFO" >"$FILE"
|
|
fi
|