[docs] Update release-process.md

- Create a release notes draft wiki for collaborative editing at https://github.com/bitcoin-core/bitcoin-devwiki/wiki as seen for releases 0.17.0 and 0.18.0.

- As per http://www.erisian.com.au/bitcoin-core-dev/log-2019-03-28.html#l-342, for the period during which the notes are being edited on the wiki, the version on the branch should be wiped and replaced with a link to the wiki which should be used for all announcements until final.

- Before final, remove the "Needs release note" label from relevant PRs/issues and merge the release notes from the wiki into the branch.

- Create a pinned meta-issue dedicated to testing the release candidate and communicate it in release announcements where useful. The former is done in practice (e.g. #15555, #14902) and the latter addresses the discussion here: https://x0f.org/web/statuses/101753569204220416.

- Adapt and merge the updates in https://github.com/bitcoin/bitcoin/pull/15692.

- Update the version numbers in all the examples.

- Reorganise the headers in the Branch Updates section.
This commit is contained in:
Jon Atack 2019-03-15 14:23:40 +01:00
parent 14959753a4
commit 96d32a7bc0
No known key found for this signature in database
GPG key ID: 4F5721B3D0E3921D

View file

@ -1,17 +1,19 @@
Release Process
====================
Before every release candidate:
## Branch updates
### Before every release candidate
* Update translations (ping wumpus on IRC) see [translation_process.md](https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md#synchronising-translations).
* Update manpages, see [gen-manpages.sh](https://github.com/bitcoin/bitcoin/blob/master/contrib/devtools/README.md#gen-manpagessh).
* Update release candidate version in `configure.ac` (`CLIENT_VERSION_RC`).
Before every minor and major release:
### Before every major and minor 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`).
* Write release notes (see below).
* Write release notes (see "Write the release notes" 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.
@ -19,13 +21,12 @@ Before every minor and major release:
- 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:
### Before every major release
* Update hardcoded [seeds](/contrib/seeds/README.md), see [this pull request](https://github.com/bitcoin/bitcoin/pull/7415) for an example.
* Update [`src/chainparams.cpp`](/src/chainparams.cpp) m_assumed_blockchain_size and m_assumed_chain_state_size with the current size plus some overhead.
* 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.
* Update version of `contrib/gitian-descriptors/*.yml`: usually one'd want to do this on master after branching off the release - but be sure to at least do it before a new major release.
* In `configure.ac` and `build_msvc/bitcoin_config.h` on _the master branch_:
- update `CLIENT_VERSION_MINOR` version
* In `configure.ac` and `build_msvc/bitcoin_config.h` on _a new release branch_ (see [this commit](https://github.com/bitcoin/bitcoin/commit/742f7dd972fca3dd4a33cfff90bf901b71a687e7)):
@ -33,6 +34,26 @@ Before every major release:
- set `CLIENT_VERSION_REVISION` to `0`
- set `CLIENT_VERSION_IS_RELEASE` to `true`
#### Before branch-off
- Clear the release notes and move them to the wiki (see "Write the release notes" below).
#### After branch-off (on master)
- Update the version of `contrib/gitian-descriptors/*.yml`.
#### After branch-off (on the major release branch)
- Update the versions and the link to the release notes draft in `doc/release-notes.md`.
#### Before final release
- Merge the release notes from the wiki into the branch.
- Ensure the "Needs release note" label is removed from all relevant pull requests and issues.
## Building
### First time / New builders
If you're using the automated script (found in [contrib/gitian-build.py](/contrib/gitian-build.py)), then at this point you should run it with the "--setup" command. Otherwise ignore this.
@ -45,22 +66,26 @@ Check out the source code in the following directory hierarchy.
git clone https://github.com/devrandom/gitian-builder.git
git clone https://github.com/bitcoin/bitcoin.git
### Bitcoin maintainers/release engineers, suggestion for writing release notes
### Write the release notes
Write release notes. git shortlog helps a lot, for example:
Open a draft of the release notes for collaborative editing at https://github.com/bitcoin-core/bitcoin-devwiki/wiki.
git shortlog --no-merges v(current version, e.g. 0.7.2)..v(new version, e.g. 0.8.0)
For the period during which the notes are being edited on the wiki, the version on the branch should be wiped and replaced with a link to the wiki which should be used for all announcements until `-final`.
Write the release notes. `git shortlog` helps a lot, for example:
git shortlog --no-merges v(current version, e.g. 0.19.2)..v(new version, e.g. 0.20.0)
(or ping @wumpus on IRC, he has specific tooling to generate the list of merged pulls
and sort them into categories based on labels)
and sort them into categories based on labels).
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
git log --format='- %aN' v(current version, e.g. 0.20.0)..v(new version, e.g. 0.20.1) | sort -fiu
Tag version (or release candidate) in git
Tag the version (or release candidate) in git:
git tag -s v(new version, e.g. 0.8.0)
git tag -s v(new version, e.g. 0.20.0)
### Setup and perform Gitian builds
@ -70,7 +95,7 @@ Setup Gitian descriptors:
pushd ./bitcoin
export SIGNER="(your Gitian key, ie bluematt, sipa, etc)"
export VERSION=(new version, e.g. 0.8.0)
export VERSION=(new version, e.g. 0.20.0)
git fetch
git checkout v${VERSION}
popd
@ -323,9 +348,11 @@ bitcoin.org (see below for bitcoin.org update instructions).
- This repo
- Archive release notes for the new version to `doc/release-notes/` (branch `master` and branch of the release)
- 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.
- Create a [new GitHub release](https://github.com/bitcoin/bitcoin/releases/new) with a link to the archived release notes
- Create a pinned meta-issue for testing the release candidate (see [this issue](https://github.com/bitcoin/bitcoin/issues/15555) for an example) and provide a link to it in the release announcements where useful
- Announce the release: