Make test constant consistent with consensus.h
[bitcoinplatinum.git] / README.md
blob38a90dde4969f6a00ce1ceb17df7c2d8dd532605
1 Bitcoin Core integration/staging tree
2 =====================================
4 [![Build Status](https://travis-ci.org/bitcoin/bitcoin.svg?branch=master)](https://travis-ci.org/bitcoin/bitcoin)
6 https://bitcoincore.org
8 What is Bitcoin?
9 ----------------
11 Bitcoin is an experimental digital currency that enables instant payments to
12 anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate
13 with no central authority: managing transactions and issuing money are carried
14 out collectively by the network. Bitcoin Core is the name of open source
15 software which enables the use of this currency.
17 For more information, as well as an immediately useable, binary version of
18 the Bitcoin Core software, see https://bitcoin.org/en/download, or read the
19 [original whitepaper](https://bitcoincore.org/bitcoin.pdf).
21 License
22 -------
24 Bitcoin Core is released under the terms of the MIT license. See [COPYING](COPYING) for more
25 information or see https://opensource.org/licenses/MIT.
27 Development Process
28 -------------------
30 The `master` branch is regularly built and tested, but is not guaranteed to be
31 completely stable. [Tags](https://github.com/bitcoin/bitcoin/tags) are created
32 regularly to indicate new official, stable release versions of Bitcoin Core.
34 The contribution workflow is described in [CONTRIBUTING.md](CONTRIBUTING.md).
36 The developer [mailing list](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev)
37 should be used to discuss complicated or controversial changes before working
38 on a patch set.
40 Developer IRC can be found on Freenode at #bitcoin-core-dev.
42 Testing
43 -------
45 Testing and code review is the bottleneck for development; we get more pull
46 requests than we can review and test on short notice. Please be patient and help out by testing
47 other people's pull requests, and remember this is a security-critical project where any mistake might cost people
48 lots of money.
50 ### Automated Testing
52 Developers are strongly encouraged to write [unit tests](src/test/README.md) for new code, and to
53 submit new unit tests for old code. Unit tests can be compiled and run
54 (assuming they weren't disabled in configure) with: `make check`. Further details on running
55 and extending unit tests can be found in [/src/test/README.md](/src/test/README.md).
57 There are also [regression and integration tests](/qa) of the RPC interface, written
58 in Python, that are run automatically on the build server.
59 These tests can be run (if the [test dependencies](/qa) are installed) with: `qa/pull-tester/rpc-tests.py`
61 The Travis CI system makes sure that every pull request is built for Windows, Linux, and OS X, and that unit/sanity tests are run automatically.
63 ### Manual Quality Assurance (QA) Testing
65 Changes should be tested by somebody other than the developer who wrote the
66 code. This is especially important for large or high-risk changes. It is useful
67 to add a test plan to the pull request description if testing the changes is
68 not straightforward.
70 Translations
71 ------------
73 Changes to translations as well as new translations can be submitted to
74 [Bitcoin Core's Transifex page](https://www.transifex.com/projects/p/bitcoin/).
76 Translations are periodically pulled from Transifex and merged into the git repository. See the
77 [translation process](doc/translation_process.md) for details on how this works.
79 **Important**: We do not accept translation changes as GitHub pull requests because the next
80 pull from Transifex would automatically overwrite them again.
82 Translators should also subscribe to the [mailing list](https://groups.google.com/forum/#!forum/bitcoin-translators).