Repository navigation
feat: Set client version for non-release binaries and version in guix based on git tags - #5653
Merged
Merged
Conversation
Member
|
I don't understand the dev / gitarc postfixes |
Author
|
Basically, when you clone the repo and build binaries it's Also, if you tag and try to build release binaries but forget to set If you don't like their names, I'm open for suggestions :) |
Member
|
But what circumstances will result in |
Author
|
release binaries: no suffixes non-release binaries:
|
Member
|
When you say "non-release binaries" do you mean building from any commit that doesn't have a tag directly on it? |
|
This pull request has conflicts, please rebase. |
Author
|
I mean binaries with |
UdjinM6
force-pushed
the
feat_tagged_version
branch
from
October 30, 2023 15:26
2d1279a to
767e8b7
Compare
Author
|
rebased to fix merge conflicts after rc bump (#5656), no other changes |
Member
|
But in that case wouldn't building v20.0.0-beta.8 result in being shown v20.0.0-beta.8-dev? |
Author
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
reviewed
Oct 30, 2023
Collaborator
There was a problem hiding this comment.
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
Author
There was a problem hiding this comment.
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
|
This pull request has conflicts, please rebase. |
UdjinM6
force-pushed
the
feat_tagged_version
branch
from
November 14, 2023 15:46
767e8b7 to
47e38de
Compare
UdjinM6
force-pushed
the
feat_tagged_version
branch
from
November 16, 2023 13:59
f26c36e to
15ba58f
Compare
Author
|
knst
previously approved these changes
Nov 16, 2023
Member
There was a problem hiding this comment.
CLIENT_VERSION_RC was dropped
Member
There was a problem hiding this comment.
dropping the RC here? Ah, rc is purely based on tag now
Member
|
I don't think this is working as intended with a tag at head building from |
Member
|
Even with a more normal looking tag this is problematic |
Member
|
Ahh; I must do |
|
This pull request has conflicts, please rebase. |
UdjinM6
force-pushed
the
feat_tagged_version
branch
from
December 16, 2023 10:47
15ba58f to
560cebc
Compare
This comment was marked as outdated.
This comment was marked as outdated.
UdjinM6
force-pushed
the
feat_tagged_version
branch
from
December 24, 2023 14:02
502673a to
42ea1ef
Compare
This comment was marked as outdated.
This comment was marked as outdated.
UdjinM6
force-pushed
the
feat_tagged_version
branch
from
December 24, 2023 14:10
42ea1ef to
53c2c13
Compare
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
…e it's aligned with scripts in `contrib/guix`
UdjinM6
force-pushed
the
feat_tagged_version
branch
from
December 24, 2023 18:41
53c2c13 to
d0b3e25
Compare
Member
|
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. |
Member
|
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. |
Author
|
UdjinM6
marked this pull request as ready for review
December 25, 2023 06:44
Author
Good catch! Should be working now. |
PastaPastaPasta
approved these changes
Dec 28, 2023
PastaPastaPasta
left a comment
PastaPastaPasta
left a comment
Member
There was a problem hiding this comment.
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
Member
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 |
2 of 3 tasks
PastaPastaPasta
added a commit
that referenced
this pull request
Sep 22, 2026
Prepare develop for tagging v24.0.0-rc.1. CLIENT_VERSION_IS_RELEASE stays false: release candidates are tagged on develop and non-release builds take their version string from the git tag (#5653). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
PastaPastaPasta
added a commit
that referenced
this pull request
Sep 22, 2026
22ff7e1 chore: set v24 testnet signalling start time (pasta) 8a4fe18 chore: bump version to 24.0.0 for v24 release candidates (pasta) Pull request description: ## Issue being fixed or feature implemented This gets develop ready for tagging v24.0.0-rc.1. Release candidates are tagged on develop itself, so develop needs to report 24.0.0 and testnet needs a concrete V24 signalling start time. The scope is deliberately narrow. Mainnet deployment parameters will follow in a separate PR. `MIN_MASTERNODE_PROTO_VERSION` is in its own PR. Release notes, chain work/assumevalid, checkpoints and seeds are not touched here. ## What was done? **1. `configure.ac`: 23.1.8 -> 24.0.0, `_CLIENT_VERSION_IS_RELEASE` stays `false`.** This follows the v23 precedent. f819f1b ("chore: bump develop to merging for v23") moved develop to 23.0.0, and `v23.0.0-rc.1` was tagged with `MAJOR 23 / MINOR 0 / BUILD 0 / IS_RELEASE false`. Dash has no `_CLIENT_VERSION_RC` define: non-release builds take their version string from `git describe` (#5653), so the RC tag supplies the `-rc.1` suffix. I grepped for `23.1.8` / `230108` / `CLIENT_VERSION_*` to find anything else that carries the version. Nothing else needs to change in this PR: - `doc/Doxyfile.in`, `share/qt/Info.plist.in`, `share/setup.nsi.in` and `src/bitcoin-util-res.rc` are substituted from the configure values automatically. - `contrib/guix` gets its version from the git tag. - `CMakeLists.txt` on develop is the IDE helper and carries no version. - No test fixtures reference the version. - `doc/man/*.1` (v23.1.8) and `contrib/flatpak/org.dash.dash-core.metainfo.xml` are left alone on purpose. `doc/release-process.md` treats both as release-time steps, and at `v23.0.0-rc.1` the man pages still said v22.1.0; they were regenerated for the final release (#6928). **2. `src/chainparams.cpp`: testnet `DEPLOYMENT_V24.nStartTime` = `1790208000` (Thursday, September 24, 2026 00:00:00 UTC).** The format follows 15ba788 (#5567). `nTimeout` (`NO_TIMEOUT`), the 100-block window and the 80 -> 60 threshold are unchanged. Mainnet stays `NEVER_ACTIVE` with its TODO. Devnet and regtest are untouched. **This start time is a placeholder, and maintainers may want to move it.** Every v24-gated consensus change still pending has to be merged and running on testnet nodes before activation. ### What actually happens after the start time (EHF, `useEHF = true`) - **Signing.** Nothing can happen until the testnet tip's median-time-past reaches `nStartTime`, which is roughly 6 blocks (~15 min) after the wall-clock time. From then on, `CEHFSignalsHandler::UpdatedBlockTip` sees that `IsValidMNActivation(12, MTP)` is in range and no bit-12 signal is known, so members of the `LLMQ_50_60` quorum sign the bit-12 MnEHF request. The recovered signature becomes an `MNHF_SIGNAL` special transaction that miners include. - **Versionbits.** Once that transaction is mined at height H, `SignalHeight()` returns H. The deployment moves `DEFINED -> STARTED` at the first 100-block period boundary at or after H. Miners then set bit 12, and the fork locks in once a full 100-block window has >= 80 signalling blocks. After the first window that threshold decays by `n^2/5` per failed window, down to a floor of 60 after 10 windows. `ACTIVE` follows one window after `LOCKED_IN`. So the earliest activation is about 200-300 blocks (~8-12.5 h) after the signal is mined: a few hours after the start time at the very soonest. - **A bit-12 signal already exists on testnet.** MnEHF tx `d6220b5d9ca0318f24befcf0e6a748bb84836bd79efbdcf165867da638292220` sits in block 1349780 (MTP 2025-10-22). Today's nodes use `nStartTime = NEVER_ACTIVE` (-2), so `IsValidMNActivation` treats any time as in range and they accepted it. With this PR, `CMNHFManager::GetSignalsStage` marks that signal as expired because its MTP is before the new `nStartTime`, so v24 nodes need a *new* signal after the start time. I confirmed this on a copy of a synced testnet datadir running this branch offline. It logs `mnhf signal bit=12 height:1349780 is expired`, and `getdeploymentinfo` shows `v24` as `defined` with `start_time 1790208000`. - **Consequence for non-upgraded testnet nodes.** This part comes from reading the v23.1.8 code; I did not test it on a network. On v23.1.8 the old signal never expires, because `signal_time < -2` is never true. So a block containing the new bit-12 MnEHF tx fails `CMNHFManager::ProcessBlock` there with `bad-mnhf-duplicate`. Old nodes therefore split off when the new signal is mined, soon after the start time, not at activation. Old miners skip the duplicate signal in block assembly and keep extending their own chain. In practice, testnet nodes (masternodes and miners in particular) need to run the RC before the start time, and that is one more reason to pick a date that leaves room after rc.1 is published. ## How Has This Been Tested? Tested on macOS arm64 (Darwin 25.5), `./configure --without-gui --disable-bench --disable-fuzz-binary` against an existing depends prefix: - `make -j12` builds cleanly. Built with `BITCOIN_GENBUILD_NO_GIT=1`, `src/dashd -version` reports `Dash Core version v24.0.0-unk`, and `bitcoin-config.h` has `PACKAGE_VERSION "24.0.0"`. With git build info the version string comes from `git describe`, so it only shows `v24.0.0-rc.1` once that tag exists. - `src/test/test_dash --run_test=versionbits_tests,evo_mnhf_tests,argsman_tests` passes (no errors). - `test/functional/test_runner.py feature_mnehf.py feature_versionbits_warning.py rpc_blockchain.py` passes: `feature_mnehf.py`, `feature_versionbits_warning.py`, and `rpc_blockchain.py` under both v1 and v2 transport. These run on regtest, where the V24 params are unchanged, so they show that the EHF/versionbits machinery is unaffected. They do not exercise the new testnet value. - I started this branch's `dashd` offline (`-connect=0`) on an APFS clone of a testnet datadir synced to height 1549291 and checked `getdeploymentinfo`, plus the expired-signal log line described above. - `test/lint/lint-whitespace.py` passes. `src/chainparams.cpp` is not in `test/util/data/non-backported.txt`, so the clang-format CI job does not cover it; the comment column follows the existing alignment and the #5567 precedent. ## Breaking Changes Testnet only. After 2026-09-24 00:00 UTC, v24 masternodes on testnet will sign and mine a new bit-12 MnEHF signal, and testnet nodes running v23.x or older develop builds will reject the block that contains it (see above). Mainnet behaviour is unchanged. Apart from the version string, nothing else changes. ## Checklist: - [x] I have performed a self-review of my own code - [ ] 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)_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) Top commit has no ACKs. Tree-SHA512: e1b6098a950327cfeab0c13f48ce9f1c0803e6df08333a5a2fbac865da9b02edf550710cd7dd0b211a54f33abe9fe132fec32cf78b289ddacd0358daa70a7e3f
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue being fixed or feature implemented
Client version string is inconsistent. Building
v20.0.0-beta.8tag locally produces binaries that reportv20.0.0-beta.8version but binaries built in guix would reportv20.0.0rc1-g3e732a952226a20505f907e4fd9b3fdbb14ea5eeinstead. Building any commit afterv20.0.0-beta.8locally would result in versions likev20.0.0rc1-8c94153d2497which is close but it's still yet another format. And both versions withrc1in their names are confusing cause you'd expect them to mentionbeta.8instead 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-devorv20.0.0-beta.8-gitarcv20.0.0-beta.8post-tag:
v20.0.0-beta.8-1-gb837e08164-gitarcv20.0.0-beta.8-1-gb837e08164post-tag format is
recent tag-commits since that tag-g+12 chars of commit hash-dirty (optional)-dev or gitarcdev/gitarcsuffixes 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_VERSIONfromconfigurelike before.Also,
CLIENT_VERSION_RCis no longer used in this setup so it was removed.Few things aren't clear to me yet:
configure.acno longer affects the reported version (unless it's an actual release). Are there any downsides I might be missing?developonce we bump version in configure?v21.0.0-init?v21.0.0-alpha1?merge master back into developkind of PR is merged? E.g. saydevelopbranch is onv21.0.0-alpha1tag and we merge v20.1.0 frommasterback into it. Will this bringv20.1.0release tag intodevelop? Will it become the one that will be used from that moment? If so we will probably need another tag ondevelopevery 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: