# bitcoin/bitcoin: three release lines and a testing bottleneck > The C++ integration tree behind Bitcoin Core, released under the MIT license, where the master branch is built and tested continuously but is not guaranteed stable. Three maintained release versions, 29 through 31, ship side by side, and code review, not coding, is what slows the project down. **bitcoin/bitcoin** — Bitcoin Core integration/staging tree. Development Process The master branch is regularly built (see doc/build-*.md for instructions) and tested, but it is not guaranteed to be completely stable. - Repository: https://github.com/bitcoin/bitcoin - Website: https://bitcoincore.org/en/download - Stars: 90,277 · Forks: 39,418 - Language: C++ - License: MIT - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/bitcoin-bitcoin ## Three release versions publish at the same time Bitcoin Core is not on one version. The recent releases include v29.4, v30.3, and v31.1, all landing within days of each other in July 2026. That is three release lines maintained in parallel, and the README explains how they relate to each other: tags are created regularly from release branches to mark new official, stable versions. Consequence for the reader: there is no single current version to name, and the newest tag is not automatically the one you want. A node operator picking a release has to choose a line, not a tag, and a line you choose today will be getting bug fixes on its own schedule rather than on the schedule of whatever is newest. The project also asks that you not treat the default branch as a substitute, since the stable artifacts are the tags, and a patch released to one line will not appear in the others. ## The master branch is a staging tree, not a release The repository's own description calls itself an integration or staging tree, and the development process section says the master branch is regularly built and tested but is not guaranteed to be completely stable. The stable artifacts come from the tags cut off the release branches, not from the default branch. Consequence for the reader: a deployment that tracks master is running code the project explicitly declines to promise is stable, so the branch you build from decides the risk you take. This is also why the last-push date and the release dates tell you different things, one is the tip of development and the others are the published, supported versions. ## The GUI is developed in a separate repository Not everything lives here. The README says the bitcoin-core/gui repository is used exclusively for development of the graphical interface, that its master branch is identical across all the monotree repositories, and that it has no release branches and tags. It even asks that you not fork it unless it is for development reasons. The integration tree here includes a wallet and a graphical user interface that can be optionally built, so the code is present, but the work on the interface happens elsewhere. Consequence for the reader: if your interest is the desktop application rather than the node, this repository is the wrong place to look, and the two master branches being kept identical is the mechanism that stops them from drifting. ## Testing and review, not writing, is the stated bottleneck The project names its own constraint without hedging. The README says testing and code review is the bottleneck for development, that the project receives more pull requests than it can review and test on short notice, and asks people to be patient and to help by testing other people's pull requests. It reminds contributors this is a security-critical project where any mistake might cost people a lot of money. Consequence for the reader: the limit on how fast this codebase changes is human review bandwidth, not engineering capacity. If you are evaluating the project on responsiveness, a large backlog of pull requests is the expected steady state, and the request for outside testing is a real and ongoing ask rather than a formality. ## Two test suites, one in C++ and one in Python There are two distinct test layers and they are run differently. Unit tests can be compiled and run, assuming they were not disabled when the build system was generated, and the README gives the command for that. Regression and integration tests are written in Python and run through a separate runner, with the caveat that the test dependencies have to be installed first and that the path assumes build is your build directory. ```bash ctest ``` ```bash build/test/functional/test_runner.py ``` Consequence for the reader: a full local test run is two different tools with two different setup steps, and the Python suite will not do anything useful until its dependencies are in place. Continuous integration tests every pull request on Windows, Linux, and macOS, and it has to pass on all of them before merge, so a contributor learns about a platform break from CI rather than from their own machine. ## Changes are supposed to be tested by someone other than the author Beyond automation, the project asks for human review of a specific kind. The manual quality assurance section says changes should be tested by somebody other than the developer who wrote the code, calls this especially important for large or high-risk changes, and suggests adding a test plan to the pull request description when testing is not straightforward. Consequence for the reader: writing tests is presented as necessary but not sufficient. A pull request from a single author, however well covered by ctest, does not meet the project's stated bar, so the review you are asking for is not a rubber stamp and it is not optional for a change someone would call risky. ## Translations cannot be contributed as pull requests Localization runs through Transifex rather than through the normal contribution path. The README points to Bitcoin Core's Transifex page, says translations are periodically pulled from Transifex and merged into the git repository, and links a translation process document for the details. It also states plainly that translation changes are not accepted as GitHub pull requests, because the next pull from Transifex would overwrite them. Consequence for the reader: this is the one kind of contribution the standard workflow deliberately closes off. A translator who opens a pull request will have their work discarded by the next automated sync, so translations move through Transifex, and the repository is a mirror of that system rather than its source. ## Conclusion This tree suits a developer who wants the reference node rather than a wrapper, and who is prepared to work under a review culture that the project itself describes as its main constraint. It does not suit someone looking for a ready binary, because the README points those readers to bitcoincore.org for a usable download and this repository is the source, not the product. Before you build from it, read doc/build-*.md for the instructions for your platform, decide which of the parallel release lines you actually want, since three are published at once, and understand that master is a staging tree, so a stable deployment should come from a tagged release branch rather than from the default branch. ## FAQ ### What is Bitcoin Core and what does this repository contain? Bitcoin Core connects to the Bitcoin peer-to-peer network to download and fully validate blocks and transactions. It also includes a wallet and a graphical user interface, which can be optionally built, and it is released under the MIT license. ### Is the master branch of bitcoin/bitcoin safe to run in production? The README says the master branch is regularly built and tested but is not guaranteed to be completely stable, and calls the repository an integration or staging tree. Official stable versions are the tags created from release branches, so a production deployment should use a tagged release rather than the default branch. ### Which version of Bitcoin Core should I use? Several versions are maintained at once. The recent release list includes v29.4, v30.3, and v31.1, all from July 2026, and tags are cut from release branches to mark official stable versions. You pick a release line rather than the newest tag, and each line receives its own fixes. ### How do I run the tests for bitcoin/bitcoin? Unit tests are compiled and run with ctest, provided they were not disabled when the build system was generated. Regression and integration tests are written in Python and run with build/test/functional/test_runner.py, which assumes build is your build directory and requires the test dependencies to be installed first. ### How do I build Bitcoin Core from this repository? The README does not give a build command itself; it points to the build instructions in the doc folder, referenced as doc/build-*.md. If you want a ready binary rather than a build, it directs you to the download page at bitcoincore.org instead. ### Can I submit a translation change as a pull request to bitcoin/bitcoin? No. The README states that translation changes are not accepted as GitHub pull requests, because the next pull from Transifex would overwrite them. Translations are submitted through Bitcoin Core's Transifex page and are periodically pulled into the repository. ## Sources - [Official documentation](https://bitcoincore.org/en/download) - [Official README](https://github.com/bitcoin/bitcoin#readme) - [Project repository](https://github.com/bitcoin/bitcoin) - [Release notes](https://github.com/bitcoin/bitcoin/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bitcoin-bitcoin