mirror of
https://github.com/dashpay/dash.git
synced 2024-12-24 19:42:46 +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)_ |
||
|---|---|---|
| .. | ||
| man | ||
| release-notes/dash | ||
| .gitignore | ||
| assets-attribution.md | ||
| benchmarking.md | ||
| bips.md | ||
| bitcoin_logo_doxygen.png | ||
| build-freebsd.md | ||
| build-netbsd.md | ||
| build-openbsd.md | ||
| build-osx.md | ||
| build-unix.md | ||
| build-windows.md | ||
| dash-conf.md | ||
| dependencies.md | ||
| descriptors.md | ||
| developer-notes.md | ||
| dnsseed-policy.md | ||
| Doxyfile.in | ||
| files.md | ||
| fuzzing.md | ||
| guix.md | ||
| i2p.md | ||
| init.md | ||
| instantsend.md | ||
| JSON-RPC-interface.md | ||
| managing-wallets.md | ||
| masternode-budget.md | ||
| productivity.md | ||
| psbt.md | ||
| README_doxygen.md | ||
| README_windows.txt | ||
| README.md | ||
| reduce-memory.md | ||
| reduce-traffic.md | ||
| release-notes-5342.md | ||
| release-notes-5493.md | ||
| release-notes-5742.md | ||
| release-notes-5765.md | ||
| release-notes-5774.md | ||
| release-notes-5775.md | ||
| release-notes-5776.md | ||
| release-notes-15367.md | ||
| release-notes-16525.md | ||
| release-notes-18309.md | ||
| release-notes-18982.md | ||
| release-notes-19725.md | ||
| release-notes-22407.md | ||
| release-notes-26896.md | ||
| release-notes-bitcoin-17219.md | ||
| release-notes.md | ||
| release-process.md | ||
| REST-interface.md | ||
| shared-libraries.md | ||
| tor.md | ||
| translation_process.md | ||
| translation_strings_policy.md | ||
| zmq.md | ||
Dash Core
This is the official reference wallet for Dash digital currency and comprises the backbone of the Dash peer-to-peer network. You can download Dash Core or build it yourself using the guides below.
Running
The following are some helpful notes on how to run Dash Core on your native platform.
Unix
Unpack the files into a directory and run:
bin/dash-qt(GUI) orbin/dashd(headless)
Windows
Unpack the files into a directory, and then run dash-qt.exe.
macOS
Drag Dash Core to your applications folder, and then run Dash Core.
Need Help?
- See the Dash documentation for help and more information.
- Ask for help on Dash Discord
- Ask for help on the Dash Forum
Building
The following are developer notes on how to build Dash Core on your native platform. They are not complete guides, but include notes on the necessary libraries, compile flags, etc.
- Dependencies
- macOS Build Notes
- Unix Build Notes
- Windows Build Notes
- OpenBSD Build Notes
- NetBSD Build Notes
- Android Build Notes
Development
The Dash Core repo's root README contains relevant information on the development process and automated testing.
- Developer Notes
- Productivity Notes
- Release Notes
- Release Process
- Source Code Documentation TODO
- Translation Process
- Translation Strings Policy
- JSON-RPC Interface
- Unauthenticated REST Interface
- Shared Libraries
- BIPS
- Dnsseed Policy
- Benchmarking
Resources
- See the Dash Developer Documentation for technical specifications and implementation details.
- Discuss on the Dash Forum, in the Development & Technical Discussion board.
- Discuss on Dash Discord
- Discuss on Dash Developers Discord
Miscellaneous
- Assets Attribution
- dash.conf Configuration File
- Files
- Fuzz-testing
- I2P Support
- Init Scripts (systemd/upstart/openrc)
- Managing Wallets
- PSBT support
- Reduce Memory
- Reduce Traffic
- Tor Support
- ZMQ
License
Distributed under the MIT software license.