* Update translations (ping wumpus, Diapolo or tcatm on IRC) see [translation_process.md](https://github.com/bitcoin/bitcoin/blob/master/doc/translation_process.md#syncing-with-transifex)
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#syncing-with-transifex)
Before every minor and major release:
* Update [bips.md](bips.md) to account for changes since the last release.
* Update hardcoded [seeds](/contrib/seeds)
* Update version in sources (see below)
* Write release notes (see below)
* * *
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.
### First time / New builders
###First time / New builders
Check out the source code in the following directory hierarchy.
cd /path/to/your/toplevel/build
@ -16,30 +25,42 @@ Check out the source code in the following directory hierarchy.
@@ -16,30 +25,42 @@ Check out the source code in the following directory hierarchy.
###Bitcoin maintainers/release engineers, update (commit) version in sources
###Bitcoin maintainers/release engineers, update version in sources
pushd ./bitcoin
contrib/verifysfbinaries/verify.sh
configure.ac
doc/README*
doc/Doxyfile
contrib/gitian-descriptors/*.yml
src/clientversion.h (change CLIENT_VERSION_IS_RELEASE to true)
Update the following:
# tag version in git
- `configure.ac`:
- `_CLIENT_VERSION_MAJOR`
- `_CLIENT_VERSION_MINOR`
- `_CLIENT_VERSION_REVISION`
- Don't forget to set `_CLIENT_VERSION_IS_RELEASE` to `true`
- `src/clientversion.h`: (this mirrors `configure.ac` - see issue #3539)
- `CLIENT_VERSION_MAJOR`
- `CLIENT_VERSION_MINOR`
- `CLIENT_VERSION_REVISION`
- Don't forget to set `CLIENT_VERSION_IS_RELEASE` to `true`
- `doc/README.md` and `doc/README_windows.txt`
- `doc/Doxyfile`: `PROJECT_NUMBER` contains the full version
- `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
git tag -s v(new version, e.g. 0.8.0)
# write release notes. git shortlog helps a lot, for example:
Write release notes. git shortlog helps a lot, for example:
git shortlog --no-merges v(current version, e.g. 0.7.2)..v(new version, e.g. 0.8.0)
popd
* * *
(or ping @wumpus on IRC, he has specific tooling to generate the list of merged pulls
@ -48,47 +69,55 @@ Check out the source code in the following directory hierarchy.
@@ -48,47 +69,55 @@ Check out the source code in the following directory hierarchy.
git checkout v${VERSION}
popd
Ensure your gitian.sigs are up-to-date if you wish to gverify your builds against other Gitian signatures.
Ensure your gitian.sigs are up-to-date if you wish to gverify your builds against other Gitian signatures.
pushd ./gitian.sigs
git pull
popd
Ensure gitian-builder is up-to-date to take advantage of new caching features (`e9741525c` or later is recommended).
Ensure gitian-builder is up-to-date to take advantage of new caching features (`e9741525c` or later is recommended).
pushd ./gitian-builder
git pull
popd
###Fetch and create inputs: (first time, or when dependency versions change)
###Fetch and create inputs: (first time, or when dependency versions change)
@ -102,30 +131,31 @@ The gbuild invocations below <b>DO NOT DO THIS</b> by default.
@@ -102,30 +131,31 @@ The gbuild invocations below <b>DO NOT DO THIS</b> by default.
2. linux 32-bit and 64-bit dist tarballs (bitcoin-${VERSION}-linux[32|64].tar.gz)
3. windows 32-bit and 64-bit unsigned installers and dist zips (bitcoin-${VERSION}-win[32|64]-setup-unsigned.exe, bitcoin-${VERSION}-win[32|64].zip)
4. OS X unsigned installer and dist tarball (bitcoin-${VERSION}-osx-unsigned.dmg, bitcoin-${VERSION}-osx64.tar.gz)
5. Gitian signatures (in gitian.sigs/${VERSION}-<linux|{win,osx}-unsigned>/(your Gitian key)/
1. source tarball (`bitcoin-${VERSION}.tar.gz`)
2. linux 32-bit and 64-bit dist tarballs (`bitcoin-${VERSION}-linux[32|64].tar.gz`)
3. windows 32-bit and 64-bit unsigned installers and dist zips (`bitcoin-${VERSION}-win[32|64]-setup-unsigned.exe`, `bitcoin-${VERSION}-win[32|64].zip`)
4. OS X unsigned installer and dist tarball (`bitcoin-${VERSION}-osx-unsigned.dmg`, `bitcoin-${VERSION}-osx64.tar.gz`)
5. Gitian signatures (in `gitian.sigs/${VERSION}-<linux|{win,osx}-unsigned>/(your Gitian key)/`)
###Verify other gitian builders signatures to your own. (Optional)
###Verify other gitian builders signatures to your own. (Optional)
Add other gitian builders keys to your gpg keyring
Add other gitian builders keys to your gpg keyring
@ -137,11 +167,12 @@ Commit your signature to gitian.sigs:
@@ -137,11 +167,12 @@ Commit your signature to gitian.sigs:
git push # Assuming you can push to the gitian.sigs tree
popd
Wait for Windows/OS X detached signatures:
Once the Windows/OS X builds each have 3 matching signatures, they will be signed with their respective release keys.
Detached signatures will then be committed to the [bitcoin-detached-sigs](https://github.com/bitcoin/bitcoin-detached-sigs) repository, which can be combined with the unsigned apps to create signed binaries.
Wait for Windows/OS X detached signatures:
- Once the Windows/OS X builds each have 3 matching signatures, they will be signed with their respective release keys.
- Detached signatures will then be committed to the [bitcoin-detached-sigs](https://github.com/bitcoin/bitcoin-detached-sigs) repository, which can be combined with the unsigned apps to create signed binaries.
Create (and optionally verify) the signed OS X binary:
Create (and optionally verify) the signed OS X binary:
@ -169,13 +200,29 @@ Commit your signature for the signed OS X/Windows binaries:
@@ -169,13 +200,29 @@ Commit your signature for the signed OS X/Windows binaries:
git push # Assuming you can push to the gitian.sigs tree
@ -185,6 +232,15 @@ Note: check that SHA256SUMS itself doesn't end up in SHA256SUMS, which is a spur
@@ -185,6 +232,15 @@ Note: check that SHA256SUMS itself doesn't end up in SHA256SUMS, which is a spur
- Upload zips and installers, as well as `SHA256SUMS.asc` from last step, to the bitcoin.org server
into `/var/www/bin/bitcoin-core-${VERSION}`
- A `.torrent` will appear in the directory after a few minutes. Optionally help seed this torrent. To get the `magnet:` URI use:
```bash
transmission-show -m <torrentfile>
```
Insert the magnet URI into the announcement sent to mailing lists. This permits
people without access to `bitcoin.org` to download the binary distribution.
Also put it into the `optional_magnetlink:` slot in the YAML file for
bitcoin.org (see below for bitcoin.org update instructions).
- Update bitcoin.org version
- First, check to see if the Bitcoin.org maintainers have prepared a
@ -202,16 +258,18 @@ Note: check that SHA256SUMS itself doesn't end up in SHA256SUMS, which is a spur
@@ -202,16 +258,18 @@ Note: check that SHA256SUMS itself doesn't end up in SHA256SUMS, which is a spur
- Announce the release:
- Release sticky on bitcointalk: https://bitcointalk.org/index.php?board=1.0
- bitcoin-dev and bitcoin-core-dev mailing list
- Bitcoin Core announcements list https://bitcoincore.org/en/list/announcements/join/
- Bitcoin-development mailing list
- bitcoincore.org blog post
- Update title of #bitcoin on Freenode IRC
- Optionally reddit /r/Bitcoin, ... but this will usually sort out itself
- Optionally twitter, reddit /r/Bitcoin, ... but this will usually sort out itself
- Notify BlueMatt so that he can start building [the PPAs](https://launchpad.net/~bitcoin/+archive/ubuntu/bitcoin)
- Notify BlueMatt so that he can start building [the PPAs](https://launchpad.net/~bitcoin/+archive/ubuntu/bitcoin)
- Add release notes for the new version to the directory `doc/release-notes` in git master
- Add release notes for the new version to the directory `doc/release-notes` in git master
Wladimir J. van der Laan
9 years ago