boxtec
/
bitcoin
mirror of https://github.com/bitcoin/bitcoin
4
1
Fork 0
Code Issues Projects Releases Wiki Activity

Merge bitcoin/bitcoin#29645: doc: update release-process.md

Browse Source 
1ea8674316 [doc] update release-process.md and backports section of CONTRIBUTING (glozow)

Pull request description:

  While doing various release process things for the first time, I noticed some of our docs are outdated and/or confusing.

ACKs for top commit:
  achow101:
    ACK 1ea8674316

Tree-SHA512: 4ad10d4ce2c33fe15cb02599353107bb72ecb867aefc6c120cfd5cdea42aa8fa3783f9e0218c2f3815f030e0694cc8fb24011ce88358a0206cb07416a256a962
pull/30010/head
Ava Chow 6 months ago
parent 4df2d0c4ce 1ea8674316
commit 842f7fdf78
No known key found for this signature in database
GPG Key ID: 17565732E08E5E41
2 changed files with 44 additions and 46 deletions
Show Stats Download Patch File Download Diff File

7
CONTRIBUTING.md
Unescape View File

@ -418,11 +418,8 @@ Backporting
Security and bug fixes can be backported from `master` to release Security and bug fixes can be backported from `master` to release
branches. branches.
If the backport is non-trivial, it may be appropriate to open an Maintainers will do backports in batches and
additional PR to backport the change, but only after the original PR use the proper `Needs backport (...)` labels
has been merged.
Otherwise, backports will be done in batches and
the maintainers will use the proper `Needs backport (...)` labels
when needed (the original author does not need to worry about it). when needed (the original author does not need to worry about it).
A backport should contain the following metadata in the commit body: A backport should contain the following metadata in the commit body:

83
doc/release-process.md
Unescape View File

@ -5,17 +5,17 @@ Release Process
### Before every release candidate ### Before every release candidate
* Update translations see [translation_process.md](https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md#synchronising-translations).
* Update release candidate version in `configure.ac` (`CLIENT_VERSION_RC`). * Update release candidate version in `configure.ac` (`CLIENT_VERSION_RC`).
* Update manpages (after rebuilding the binaries), see [gen-manpages.py](https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/README.md#gen-manpagespy). * Update manpages (after rebuilding the binaries), see [gen-manpages.py](https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/README.md#gen-manpagespy).
* Update bitcoin.conf and commit, see [gen-bitcoin-conf.sh](https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/README.md#gen-bitcoin-confsh). * Update bitcoin.conf and commit changes if they exist, see [gen-bitcoin-conf.sh](https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/README.md#gen-bitcoin-confsh).
### Before every major and minor release ### Before every major and minor release
* Update [bips.md](bips.md) to account for changes since the last 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_RC` to `0`). * Update version in `configure.ac` (don't forget to set `CLIENT_VERSION_RC` to `0`).
* Update manpages (see previous section) * Update manpages (see previous section)
* Write release notes (see "Write the release notes" below). * Write release notes (see "Write the release notes" below) in doc/release-notes.md. If necessary,
archive the previous release notes as doc/release-notes/release-notes-${VERSION}.md.
### Before every major release ### Before every major release
@ -28,6 +28,7 @@ Release Process
#### Before branch-off #### Before branch-off
* Update translations see [translation_process.md](https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md#synchronising-translations).
* Update hardcoded [seeds](/contrib/seeds/README.md), see [this pull request](https://github.com/bitcoin/bitcoin/pull/27488) for an example. * Update hardcoded [seeds](/contrib/seeds/README.md), see [this pull request](https://github.com/bitcoin/bitcoin/pull/27488) for an example.
* Update the following variables in [`src/kernel/chainparams.cpp`](/src/kernel/chainparams.cpp) for mainnet, testnet, and signet: * Update the following variables in [`src/kernel/chainparams.cpp`](/src/kernel/chainparams.cpp) for mainnet, testnet, and signet:
- `m_assumed_blockchain_size` and `m_assumed_chain_state_size` with the current size plus some overhead (see - `m_assumed_blockchain_size` and `m_assumed_chain_state_size` with the current size plus some overhead (see
@ -161,6 +162,8 @@ Then open a Pull Request to the [guix.sigs repository](https://github.com/bitcoi
### macOS codesigner only: Create detached macOS signatures (assuming [signapple](https://github.com/achow101/signapple/) is installed and up to date with master branch) ### macOS codesigner only: Create detached macOS signatures (assuming [signapple](https://github.com/achow101/signapple/) is installed and up to date with master branch)
In the `guix-build-${VERSION}/output/x86_64-apple-darwin` and `guix-build-${VERSION}/output/arm64-apple-darwin` directories:
tar xf bitcoin-osx-unsigned.tar.gz tar xf bitcoin-osx-unsigned.tar.gz
./detached-sig-create.sh /path/to/codesign.p12 ./detached-sig-create.sh /path/to/codesign.p12
Enter the keychain password and authorize the signature Enter the keychain password and authorize the signature
@ -168,6 +171,8 @@ Then open a Pull Request to the [guix.sigs repository](https://github.com/bitcoi
### Windows codesigner only: Create detached Windows signatures ### Windows codesigner only: Create detached Windows signatures
In the `guix-build-${VERSION}/output/x86_64-w64-mingw32` directory:
tar xf bitcoin-win-unsigned.tar.gz tar xf bitcoin-win-unsigned.tar.gz
./detached-sig-create.sh -key /path/to/codesign.key ./detached-sig-create.sh -key /path/to/codesign.key
Enter the passphrase for the key when prompted Enter the passphrase for the key when prompted
@ -175,18 +180,22 @@ Then open a Pull Request to the [guix.sigs repository](https://github.com/bitcoi
### Windows and macOS codesigners only: test code signatures ### Windows and macOS codesigners only: test code signatures
It is advised to test that the code signature attaches properly prior to tagging by performing the `guix-codesign` step. It is advised to test that the code signature attaches properly prior to tagging by performing the `guix-codesign` step.
However if this is done, once the release has been tagged in the bitcoin-detached-sigs repo, the `guix-codesign` step must be performed again in order for the guix attestation to be valid when compared against the attestations of non-codesigner builds. However if this is done, once the release has been tagged in the bitcoin-detached-sigs repo, the `guix-codesign` step must be performed again in order for the guix attestation to be valid when compared against the attestations of non-codesigner builds. The directories created by `guix-codesign` will need to be cleared prior to running `guix-codesign` again.
### Windows and macOS codesigners only: Commit the detached codesign payloads ### Windows and macOS codesigners only: Commit the detached codesign payloads
```sh ```sh
pushd ./bitcoin-detached-sigs pushd ./bitcoin-detached-sigs
# checkout the appropriate branch for this release series # checkout or create the appropriate branch for this release series
rm -rf ./* git checkout --orphan <branch>
# if you are the macOS codesigner
rm -rf osx
tar xf signature-osx.tar.gz tar xf signature-osx.tar.gz
# if you are the windows codesigner
rm -rf win
tar xf signature-win.tar.gz tar xf signature-win.tar.gz
git add -A git add -A
git commit -m "point to ${VERSION}" git commit -m "<version>: {osx,win} signature for {rc,final}"
git tag -s "v${VERSION}" HEAD git tag -s "v${VERSION}" HEAD
git push the current branch and new tag git push the current branch and new tag
popd popd
@ -216,45 +225,36 @@ popd
Then open a Pull Request to the [guix.sigs repository](https://github.com/bitcoin-core/guix.sigs). Then open a Pull Request to the [guix.sigs repository](https://github.com/bitcoin-core/guix.sigs).
## After 3 or more people have guix-built and their results match ## After 6 or more people have guix-built and their results match
Combine the `all.SHA256SUMS.asc` file from all signers into `SHA256SUMS.asc`: After verifying signatures, combine the `all.SHA256SUMS.asc` file from all signers into `SHA256SUMS.asc`:
```bash ```bash
cat "$VERSION"/*/all.SHA256SUMS.asc > SHA256SUMS.asc cat "$VERSION"/*/all.SHA256SUMS.asc > SHA256SUMS.asc
``` ```
- Upload to the bitcoincore.org server (`/var/www/bin/bitcoin-core-${VERSION}/`): - Upload to the bitcoincore.org server:
1. The contents of each `./bitcoin/guix-build-${VERSION}/output/${HOST}/` directory, except for 1. The contents of each `./bitcoin/guix-build-${VERSION}/output/${HOST}/` directory.
`*-debug*` files.
Guix will output all of the results into host subdirectories, but the SHA256SUMS Guix will output all of the results into host subdirectories, but the SHA256SUMS
file does not include these subdirectories. In order for downloads via torrent file does not include these subdirectories. In order for downloads via torrent
to verify without directory structure modification, all of the uploaded files to verify without directory structure modification, all of the uploaded files
need to be in the same directory as the SHA256SUMS file. need to be in the same directory as the SHA256SUMS file.
The `*-debug*` files generated by the guix build contain debug symbols Wait until all of these files have finished uploading before uploading the SHA256SUMS(.asc) files.
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 bitcoincore.org server,
nor put them in the torrent*.
```sh
find guix-build-${VERSION}/output/ -maxdepth 2 -type f -not -name "SHA256SUMS.part" -and -not -name "*debug*" -exec scp {} user@bitcoincore.org:/var/www/bin/bitcoin-core-${VERSION} \;
```
2. The `SHA256SUMS` file 2. The `SHA256SUMS` file
3. The `SHA256SUMS.asc` combined signature file you just created 3. The `SHA256SUMS.asc` combined signature file you just created.
- Create a torrent of the `/var/www/bin/bitcoin-core-${VERSION}` directory such - After uploading release candidate binaries, notify the bitcoin-core-dev mailing list and
that at the top level there is only one file: the `bitcoin-core-${VERSION}` bitcoin-dev group that a release candidate is available for testing. Include a link to the release
directory containing everything else. Name the torrent notes draft.
`bitcoin-${VERSION}.torrent` (note that there is no `-core-` in this name).
Optionally help seed this torrent. To get the `magnet:` URI use: - The server will automatically create an OpenTimestamps file and torrent of the directory.
- Optionally help seed this torrent. To get the `magnet:` URI use:
```sh ```sh
transmission-show -m <torrent file> transmission-show -m <torrent file>
@ -265,32 +265,33 @@ cat "$VERSION"/*/all.SHA256SUMS.asc > SHA256SUMS.asc
Also put it into the `optional_magnetlink:` slot in the YAML file for Also put it into the `optional_magnetlink:` slot in the YAML file for
bitcoincore.org. bitcoincore.org.
- Update other repositories and websites for new version - Archive the release notes for the new version to `doc/release-notes/release-notes-${VERSION}.md`
(branch `master` and branch of the release).
- bitcoincore.org blog post
- bitcoincore.org maintained versions update: - Update the bitcoincore.org website
[table](https://github.com/bitcoin-core/bitcoincore.org/commits/master/_includes/posts/maintenance-table.md)
- Delete post-EOL [release branches](https://github.com/bitcoin/bitcoin/branches/all) and create a tag `v${branch_name}-final`. - blog post
- Delete ["Needs backport" labels](https://github.com/bitcoin/bitcoin/labels?q=backport) for non-existing branches. - maintained versions [table](https://github.com/bitcoin-core/bitcoincore.org/commits/master/_includes/posts/maintenance-table.md)
- bitcoincore.org RPC documentation update - RPC documentation update
- See https://github.com/bitcoin-core/bitcoincore.org/blob/master/contrib/doc-gen/ - See https://github.com/bitcoin-core/bitcoincore.org/blob/master/contrib/doc-gen/
- Update repositories
- Delete post-EOL [release branches](https://github.com/bitcoin/bitcoin/branches/all) and create a tag `v${branch_name}-final`.
- Delete ["Needs backport" labels](https://github.com/bitcoin/bitcoin/labels?q=backport) for non-existing branches.
- Update packaging repo - Update packaging repo
- Push the flatpak to flathub, e.g. https://github.com/flathub/org.bitcoincore.bitcoin-qt/pull/2 - Push the flatpak to flathub, e.g. https://github.com/flathub/org.bitcoincore.bitcoin-qt/pull/2
- Push the snap, see https://github.com/bitcoin-core/packaging/blob/main/snap/local/build.md - Push the snap, see https://github.com/bitcoin-core/packaging/blob/main/snap/local/build.md
- This repo - Create a [new GitHub release](https://github.com/bitcoin/bitcoin/releases/new) with a link to the archived release notes
- Archive the 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/bitcoin/bitcoin/releases/new) with a link to the archived release notes
- Announce the release: - Announce the release:

Write Preview
Loading…
Cancel
Save