mirror of
https://github.com/dashpay/dash.git
synced 2024-12-25 12:02:48 +01:00
f54ec9cde7
fac4814106c796b8786dd90053513cc35142dfe5 doc/release-process: Add torrent creation details (Carl Dong) 5d24cc3d82dad6812f8370c3ccc7c2b5a6c12c11 guix/INSTALL: Guix installs init scripts in libdir (Carl Dong) 5da2ee49d5b44de803b671aedbdd14e5c1d71ea9 guix/INSTALL: Add coreutils/inotify-dir-recreate troubleshooting (Carl Dong) 318c60700b7bbb7ec09a29bf037e7c2787646be6 guix: Adapt release-process.md to new Guix process (Carl Dong) fcab35b2292f9221eaba521740e8b3b2511a8b78 guix-attest: Produce and sign normalized documents (Carl Dong) c2541fd0ca99481a5a792a8f2772925d64fb0491 guix: Overhaul README (Carl Dong) 46ce6ce3782dfbd8f9d26dc2ba0f284755e75f2d tree-wide: Rename gitian-keys to builder-keys (Carl Dong) fc4f8449f34e32b0b9ac9d218d6c3264b02467ba guix: Update various check_tools lists (Carl Dong) 263220a85c1df218431fafbda07c8b23ccc4ce4d guix: Check for a sane services database (Carl Dong) Pull request description: Based on: #21462 Keeping the README in one file so that it's easy to search through. Will add more jumping links later so navigation is easier. Current TODOs: - [x] Shell installer option: prompt user to re-login for `/etc/profile.d` entry to be picked up - [x] Binary tarball option: prompt user to create `/etc/profile.d` entry and re-login - [x] Fanquake docker option: complete section - [x] Arch Linux AUR option: prompt to start `guix-daemon-latest` unit after finishing "optional setup" section - [x] Building from source option: Insert dependency tree diagram that I made - [x] Building from source option: redo sectioning, kind of a mess right now - [x] Optional setup: make clear which parts are only needed if building from source - [x] Workaround 1 for GnuTLS: perhaps mention how to remove Guix build farm's key - [x] Overall (after everything): Make the links work. Note to self: wherever possible, tell user how to check that something is true rather than branching by installation option. ACKs for top commit: fanquake: ACK fac4814106c796b8786dd90053513cc35142dfe5 - going to go ahead and merge this now. It's a lot of documentation, and could probably be nit-picked / improved further, however, that can continue over the next few weeks. I'm sure more (backportable) improvements / clarifications will be made while we progress through RCs towards a new release. Tree-SHA512: dc46c0ecdfc67c7c7743ca26e4a603eb3f54adbf81be2f4c1f4c20577ebb84b5250b9c9ec89c0e9860337ab1c7cff94d7963c603287267deecfe1cd987fa070a
223 lines
8.9 KiB
Markdown
223 lines
8.9 KiB
Markdown
Release Process
|
|
====================
|
|
|
|
* Update translations, see [translation_process.md](https://github.com/dashpay/dash/blob/master/doc/translation_process.md#synchronising-translations).
|
|
|
|
* Update manpages, see [gen-manpages.sh](https://github.com/dashpay/dash/blob/master/contrib/devtools/README.md#gen-manpagessh).
|
|
* Update release candidate version in `configure.ac` (`CLIENT_VERSION_RC`)
|
|
|
|
Before every minor and major release:
|
|
|
|
* Update [bips.md](bips.md) to account for changes since the last release.
|
|
* Update version in `configure.ac` (don't forget to set `CLIENT_VERSION_IS_RELEASE` to `true`) (don't forget to set `CLIENT_VERSION_RC` to `0`)
|
|
* Write release notes (see below)
|
|
* Update `src/chainparams.cpp` nMinimumChainWork with information from the getblockchaininfo rpc.
|
|
* Update `src/chainparams.cpp` defaultAssumeValid with information from the getblockhash rpc.
|
|
- The selected value must not be orphaned so it may be useful to set the value two blocks back from the tip.
|
|
- Testnet should be set some tens of thousands back from the tip due to reorgs there.
|
|
- This update should be reviewed with a reindex-chainstate with assumevalid=0 to catch any defect
|
|
that causes rejection of blocks in the past history.
|
|
|
|
Before every major release:
|
|
|
|
* Update hardcoded [seeds](/contrib/seeds/README.md). TODO: Give example PR for Dash
|
|
* Update [`src/chainparams.cpp`](/src/chainparams.cpp) m_assumed_blockchain_size and m_assumed_chain_state_size with the current size plus some overhead (see [this](#how-to-calculate-m_assumed_blockchain_size-and-m_assumed_chain_state_size) for information on how to calculate them).
|
|
* Update `src/chainparams.cpp` chainTxData with statistics about the transaction count and rate. Use the output of the RPC `getchaintxstats`, see
|
|
[this pull request](https://github.com/bitcoin/bitcoin/pull/12270) for an example. Reviewers can verify the results by running `getchaintxstats <window_block_count> <window_last_block_hash>` with the `window_block_count` and `window_last_block_hash` from your output.
|
|
|
|
### First time / New builders
|
|
|
|
Install Guix using one of the installation methods detailed in
|
|
[contrib/guix/INSTALL.md](/contrib/guix/INSTALL.md).
|
|
|
|
Check out the source code in the following directory hierarchy.
|
|
|
|
cd /path/to/your/toplevel/build
|
|
git clone https://github.com/dashpay/guix.sigs.git
|
|
git clone https://github.com/dashpay/dash-detached-sigs.git
|
|
git clone https://github.com/dashpay/dash.git
|
|
|
|
### Dash Core maintainers/release engineers, suggestion for writing release notes
|
|
|
|
Write release notes. git shortlog helps a lot, for example:
|
|
|
|
git shortlog --no-merges v(current version, e.g. 0.12.2)..v(new version, e.g. 0.12.3)
|
|
|
|
Generate list of authors:
|
|
|
|
git log --format='- %aN' v(current version, e.g. 0.16.0)..v(new version, e.g. 0.16.1) | sort -fiu
|
|
|
|
Tag version (or release candidate) in git
|
|
|
|
git tag -s v(new version, e.g. 0.12.3)
|
|
|
|
### Setup and perform Guix builds
|
|
|
|
Checkout the Dash Core version you'd like to build:
|
|
|
|
```sh
|
|
pushd ./dash
|
|
export SIGNER='(your builder key, ie UdjinM6, Pasta, etc)'
|
|
export VERSION='(new version, e.g. 20.0.0)'
|
|
git fetch "v${VERSION}"
|
|
git checkout "v${VERSION}"
|
|
popd
|
|
```
|
|
|
|
Ensure your guix.sigs are up-to-date if you wish to `guix-verify` your builds
|
|
against other `guix-attest` signatures.
|
|
|
|
```sh
|
|
git -C ./guix.sigs pull
|
|
```
|
|
|
|
### Create the macOS SDK tarball: (first time, or when SDK version changes)
|
|
|
|
Create the macOS SDK tarball, see the [macOS build
|
|
instructions](build-osx.md#deterministic-macos-dmg-notes) for
|
|
details.
|
|
|
|
### Build and attest to build outputs:
|
|
|
|
Follow the relevant Guix README.md sections:
|
|
- [Performing a build](/contrib/guix/README.md#performing-a-build)
|
|
- [Attesting to build outputs](/contrib/guix/README.md#attesting-to-build-outputs)
|
|
|
|
### Verify other builders' signatures to your own. (Optional)
|
|
|
|
Add other builders keys to your gpg keyring, and/or refresh keys: See `../dash/contrib/builder-keys/README.md`.
|
|
|
|
Follow the relevant Guix README.md sections:
|
|
- [Verifying build output attestations](/contrib/guix/README.md#verifying-build-output-attestations)
|
|
|
|
### Next steps:
|
|
|
|
Commit your signature to guix.sigs:
|
|
|
|
```sh
|
|
pushd guix.sigs
|
|
git add "${VERSION}/${SIGNER}/noncodesigned.SHA256SUMS{,.asc}"
|
|
git commit -a
|
|
git push # Assuming you can push to the guix.sigs tree
|
|
popd
|
|
```
|
|
|
|
Codesigner only: Create Windows/macOS detached signatures:
|
|
- Only one person handles codesigning. Everyone else should skip to the next step.
|
|
- Only once the Windows/macOS builds each have 3 matching signatures may they be signed with their respective release keys.
|
|
|
|
Codesigner only: Sign the macOS binary:
|
|
|
|
transfer dashcore-osx-unsigned.tar.gz to macOS for signing
|
|
tar xf dashcore-osx-unsigned.tar.gz
|
|
./detached-sig-create.sh -s "Key ID" -o runtime
|
|
Enter the keychain password and authorize the signature
|
|
Move signature-osx.tar.gz back to the guix-build host
|
|
|
|
Codesigner only: Sign the windows binaries:
|
|
|
|
tar xf dashcore-win-unsigned.tar.gz
|
|
./detached-sig-create.sh -key /path/to/codesign.key
|
|
Enter the passphrase for the key when prompted
|
|
signature-win.tar.gz will be created
|
|
|
|
Codesigner only: Commit the detached codesign payloads:
|
|
|
|
```sh
|
|
pushd ~/dashcore-detached-sigs
|
|
# checkout the appropriate branch for this release series
|
|
rm -rf *
|
|
tar xf signature-osx.tar.gz
|
|
tar xf signature-win.tar.gz
|
|
git add -A
|
|
git commit -m "point to ${VERSION}"
|
|
git tag -s "v${VERSION}" HEAD
|
|
git push the current branch and new tag
|
|
popd
|
|
```
|
|
|
|
Non-codesigners: wait for Windows/macOS detached signatures:
|
|
|
|
- Once the Windows/macOS builds each have 3 matching signatures, they will be signed with their respective release keys.
|
|
- Detached signatures will then be committed to the [dash-detached-sigs](https://github.com/dashpay/dash-detached-sigs) repository, which can be combined with the unsigned apps to create signed binaries.
|
|
|
|
Create (and optionally verify) the codesigned outputs:
|
|
- [Codesigning](/contrib/guix/README.md#codesigning)
|
|
|
|
Commit your signature for the signed macOS/Windows binaries:
|
|
|
|
```sh
|
|
pushd ./guix.sigs
|
|
git add "${VERSION}/${SIGNER}"/all.SHA256SUMS{,.asc}
|
|
git commit -m "Add ${SIGNER} ${VERSION} signed binaries signatures"
|
|
git push # Assuming you can push to the guix.sigs tree
|
|
popd
|
|
```
|
|
|
|
### After 3 or more people have guix-built and their results match:
|
|
|
|
Combine `all.SHA256SUMS` and `all.SHA256SUMS.asc` into a clear-signed
|
|
`SHA256SUMS.asc` message:
|
|
|
|
```sh
|
|
echo -e "-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\n$(cat all.SHA256SUMS)\n$(cat filename.txt.asc)" > SHA256SUMS.asc
|
|
```
|
|
|
|
Here's an equivalent, more readable command if you're confident that you won't
|
|
mess up whitespaces when copy-pasting:
|
|
|
|
```bash
|
|
cat << EOF > SHA256SUMS.asc
|
|
-----BEGIN PGP SIGNED MESSAGE-----
|
|
Hash: SHA256
|
|
|
|
$(cat all.SHA256SUMS)
|
|
$(cat all.SHA256SUMS.asc)
|
|
EOF
|
|
```
|
|
|
|
- Upload to the dash.org server:
|
|
1. The contents of /dash/guix-build-${VERSION}/output`, except for
|
|
`*-debug*` files.
|
|
|
|
The `*-debug*` files generated by the guix build contain debug symbols
|
|
for troubleshooting by developers. It is assumed that anyone that is
|
|
interested in debugging can run guix to generate the files for
|
|
themselves. To avoid end-user confusion about which file to pick, as well
|
|
as save storage space *do not upload these to the dash.org server*.
|
|
2. The combined clear-signed message you just created `SHA256SUMS.asc`
|
|
|
|
- Announce the release:
|
|
|
|
- Release on Dash forum: https://www.dash.org/forum/topic/official-announcements.54/
|
|
|
|
- Optionally Discord, twitter, reddit /r/Dashpay, ... but this will usually sort out itself
|
|
|
|
- Notify flare so that he can start building [the PPAs](https://launchpad.net/~dash.org/+archive/ubuntu/dash)
|
|
|
|
- Archive release notes for the new version to `doc/release-notes/` (branch `master` and branch of the release)
|
|
|
|
- Create a [new GitHub release](https://github.com/dashpay/dash/releases/new) with a link to the archived release notes.
|
|
|
|
- Celebrate
|
|
|
|
### Additional information
|
|
|
|
#### How to calculate `m_assumed_blockchain_size` and `m_assumed_chain_state_size`
|
|
|
|
Both variables are used as a guideline for how much space the user needs on their drive in total, not just strictly for the blockchain.
|
|
Note that all values should be taken from a **fully synced** node and have an overhead of 5-10% added on top of its base value.
|
|
|
|
To calculate `m_assumed_blockchain_size`:
|
|
- For `mainnet` -> Take the size of the Dash Core data directory, excluding `/regtest` and `/testnet3` directories.
|
|
- For `testnet` -> Take the size of the `/testnet3` directory.
|
|
|
|
|
|
To calculate `m_assumed_chain_state_size`:
|
|
- For `mainnet` -> Take the size of the `/chainstate` directory.
|
|
- For `testnet` -> Take the size of the `/testnet3/chainstate` directory.
|
|
|
|
Notes:
|
|
- When taking the size for `m_assumed_blockchain_size`, there's no need to exclude the `/chainstate` directory since it's a guideline value and an overhead will be added anyway.
|
|
- The expected overhead for growth may change over time, so it may not be the same value as last release; pay attention to that when changing the variables.
|