General notes on hive development process

Branching methodology

Hived is being developed using a master/develop branching process. Production builds should always be made from the master branch, and only production fixes should be merged to the master branch except when an official release is ready. Normal development changes should be merged to the develop branch. We are using this process to enable fixes to be made to production systems without requiring the production fixes to reside in branches.

A side-effect of this is that someone should always be able to build a production node using the head of the master branch.

If you plan to commit your own remote branches to the repo (if you're working for more than a day or two in a branch, this is recommended), please add a prefix with your initials, so that a casual viewer of the branches list can see who is responsible for the branch.

Coding conventions

• 2 space indention (DO NOT USE TABS)
• Avoid the use of acronyms and abbreviations in source code (i.e. in variable names) and file names unless it is standard abbreviation/acronym of the English language.

Testing methodology

Unit tests in the C++ source code are used as first-level tests.

Python-based API tests are used to verify the functionality of API functions that are exposed to outside processes.

A reindexing test verifies that hived is able to process existing blocks in the blockchain. Currently this is a simple pass/fail test (the test fails if the node isn't able to process all the blocks in the blockchain). As this is a computationally intensive test, it's also a performance test.

Future testing will combine reindex testing with the generation of state files to verify that blocks are correctly processed. These tests will compare the state files generated by new versions of hived versus the state files of old versions of hived.