mirrors/bitcoin
1
0
Fork 0
mirror of https://github.com/bitcoin/bitcoin.git synced 2024-11-20 10:38:42 +01:00
Code Issues Projects Releases Wiki Activity

Merge #15607: [Docs] Release process updates

Browse Source 
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
This commit is contained in:
MarcoFalke 2019-05-10 15:57:45 -04:00
commit e79bbb73e0
No known key found for this signature in database
GPG Key ID: D2EA4850E7528B25
2 changed files with 58 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
doc/release-notes.md
View File

@ -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:

57
doc/release-process.md
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: