Bitcoin Core Release Process

Bitcoin Core release process is the documented sequence of steps that turns the project's source tree into versioned, verifiable binaries that tens of thousands of node operators can install without trusting any single party. Because Bitcoin Core validates consensus rules — software where a subtle packaging error could partition the network — the process is deliberately conservative, heavily checklisted, and recorded in the repository itself, so any contributor can follow it and any outsider can audit it.

Branching and release candidates

Development happens continuously on the master branch, but releases are cut from dedicated release branches, which isolates stabilization from ongoing feature work. For a major version, maintainers branch off, update version variables in the build configuration, and refresh the release notes, manual pages, and documentation of supported BIPs. Then come release candidates — rc1, rc2, and onward — published as real, installable builds so node operators, miners, exchanges, and wallet vendors can exercise them against production-shaped workloads before anything is final. Bugs found in candidates are fixed on the branch and a new candidate is cut; only when a candidate survives scrutiny does a maintainer create the final tag, using tooling that performs consistency checks and produces a cryptographically signed git tag. Backported bug-fix releases for prior major versions follow the same discipline on their own branches.

Deterministic builds and signing

The step that most distinguishes the project is how binaries are made. Official releases are built with a deterministic, reproducible toolchain, so independent builders on different machines can compile the same tagged source and obtain byte-for-byte identical outputs — the property covered under reproducible builds. Multiple contributors build independently and publish signed attestations of their result hashes; agreement among them is what certifies that the distributed binaries genuinely correspond to the public source, with no single compromised build machine able to slip in a backdoor. Platform code-signing (for operating systems that require it) is applied only after enough matching attestations exist. The role and accountability of the people holding these keys is covered under Bitcoin Core maintainer.

Verifying what you run

The process only pays off if users close the loop. Each release ships with a file of SHA-256 hashes and detached signatures from multiple release signers; verifying your download means checking its hash appears in that file and that enough valid signatures cover it. It takes a few minutes and converts "I trust the website I downloaded from" into "I verified the artifact against multiple independent keyholders" — the appropriate standard for software that guards money. Node runners who skip verification are trusting a TLS connection and a web host with everything.

Why the conservatism

Cadence follows readiness rather than a calendar. Major versions arrive when the branch is genuinely stable — historically on the order of once or twice a year — and there is no marketing deadline that can force one out early. Consensus-adjacent changes ride an even slower track, often spending years in review before touching a release. Users, meanwhile, are never forced forward: older major versions receive backported fixes for a window, and the network tolerates a spread of versions by design. The result is an upgrade culture built on pull rather than push — operators move when they have verified, not when they are told.

Every choice — long candidate cycles, deterministic builds, multi-party signing, documented checklists — trades speed for auditability. Feature development is debated upstream through the BIP process and merged under the project's lazy consensus norms; by the time code reaches a release branch, the release machinery's only job is to deliver it unmodified and provably so. In a system with no recall mechanism and no vendor to sue, the release process is the warranty.