aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorMarcoFalke <falke.marco@gmail.com>2019-05-10 15:57:45 -0400
committerMarcoFalke <falke.marco@gmail.com>2019-05-10 15:58:32 -0400
commite79bbb73e08e3f191e97d3b67a2fbb510c5545ff (patch)
tree0080bceab9d6fa58f59e6f9fa0c228ad1531083b /doc
parente2371f842fb9fc1ec35ea9a87a335ed0ba499aa1 (diff)
parentbd63c1ed12a69555ee90478cfa34ae315cc6f0d7 (diff)
downloadbitcoin-e79bbb73e08e3f191e97d3b67a2fbb510c5545ff.tar.xz
Merge #15607: [Docs] Release process updates
bd63c1ed12 [docs] Update release-notes.md (Jon Atack) 96d32a7bc0 [docs] Update release-process.md (Jon Atack) Pull request description: Updates to `release-notes.md`: - Write an introduction explaining how to use `release-notes.md` as a template for the release notes draft wiki for collaborative editing at https://github.com/bitcoin-core/bitcoin-devwiki/wiki, as seen for the 0.17.0 and 0.18.0 releases. Updates to `release-process.md`: - Create a release notes draft wiki at https://github.com/bitcoin-core/bitcoin-devwiki/wiki. - As per http://www.erisian.com.au/bitcoin-core-dev/log-2019-03-28.html#l-342, for the period during which the release 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. https://github.com/bitcoin/bitcoin/issues/15555, https://github.com/bitcoin/bitcoin/issues/14902) and the latter addresses the discussion here yesterday: https://x0f.org/web/statuses/101753569204220416. - Reorganise the headers in the Branch Updates section. - Update the version numbers in the examples. - Adapt and merge in the updates in https://github.com/bitcoin/bitcoin/pull/15692. ACKs for commit bd63c1: Tree-SHA512: a436d6d0971bf00f081d4e2660c3b37a0f96913236c33934453387d63c11556a80e428b110f5629f07a6aa98e627f86c799d10c3f40e9f0c27b22275e04f6fa8
Diffstat (limited to 'doc')
-rw-r--r--doc/release-notes.md18
-rw-r--r--doc/release-process.md57
2 files changed, 58 insertions, 17 deletions
diff --git a/doc/release-notes.md b/doc/release-notes.md
index 834c9b36dc..6550fd75a9 100644
--- a/doc/release-notes.md
+++ b/doc/release-notes.md
@@ -1,5 +1,19 @@
-(note: this is a temporary file, to be added-to by anybody, and moved to
-release-notes at release time)
+*After branching off for a major version release of Bitcoin Core, use this
+template to create the initial release notes draft.*
+
+*The release notes draft is a temporary file that can be added to by anyone. See
+[/doc/developer-notes.md#release-notes](/doc/developer-notes.md#release-notes)
+for the process.*
+
+*Create the draft, named* "*version* Release Notes Draft"
+*(e.g. "0.20.0 Release Notes Draft"), as a collaborative wiki in:*
+
+https://github.com/bitcoin-core/bitcoin-devwiki/wiki/
+
+*Before the final release, move the notes back to this git repository.*
+
+*version* Release Notes Draft
+===============================
Bitcoin Core version *version* is now available from:
diff --git a/doc/release-process.md b/doc/release-process.md
index 1496a48a63..9b796fa816 100644
--- a/doc/release-process.md
+++ b/doc/release-process.md
@@ -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: