consistent naming of network types

This commit is contained in:
protolambda 2019-04-05 22:31:37 +11:00
parent 4bf20a1208
commit 09ceccacb4
No known key found for this signature in database
GPG Key ID: EC89FDBB2B4C7623
1 changed files with 2 additions and 2 deletions

View File

@ -64,7 +64,7 @@ There are two types of fork-data:
2) coverage: what forks are covered by a test?
The first is neat to have as a separate form: we prevent duplication, and can run with different presets
(e.g. fork timeline for a minimal local test, for a public testnet, or for main-net)
(e.g. fork timeline for a minimal local test, for a public testnet, or for mainnet)
The second is still somewhat ambiguous: some tests may want cover multiple forks, and can do so in different ways:
- run one test, transitioning from one to the other
@ -110,7 +110,7 @@ Separation of configuration and tests aims to:
- prevent duplication of a minimal set of tests
- make all tests easy to upgrade when a new config constant is introduced.
- clearly define which constants to use
- share-able between clients, for cross-client short or long lived test-nets
- share-able between clients, for cross-client short or long lived testnets
- minimize the amounts of different constants permutations to compile as a client. \**
\**: Some clients prefer compile-time constants and optimizations.