From 30e14557f4ae5eca091b14bedb746bdc1dadf9db Mon Sep 17 00:00:00 2001 From: Callum Date: Fri, 20 Nov 2020 14:58:43 +0100 Subject: [PATCH] use bold instead of italic --- docs/architecture/adr-016-protocol-versions.md | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/docs/architecture/adr-016-protocol-versions.md b/docs/architecture/adr-016-protocol-versions.md index fc8bcb76a..45afaa61b 100644 --- a/docs/architecture/adr-016-protocol-versions.md +++ b/docs/architecture/adr-016-protocol-versions.md @@ -44,8 +44,7 @@ Ideally, each component of the software is independently versioned in a modular way and its easy to mix and match and upgrade. We can consider the complete version of the protocol to contain the following -sub-versions: - *BlockVersion*, *P2PVersion*, *AppVersion* +sub-versions: **BlockVersion**, **P2PVersion**, **AppVersion**. These versions reflect the major sub-components of the software that are likely to evolve together, at different rates, and in different ways. @@ -79,11 +78,10 @@ with the previous version. and Results are calculated in the same manner across the entire network. In addition, the block version is the parent of two further sub versions: - *RPCVersion* and *ABCIVersion*. -These are denoted using semantic versioning. Changing the block protocol will -require either a new major or minor release for each of these versions as the -data structures they serve have changed, however major and minor releases -wouldn't necessarily mean a block protocol change. +**RPCVersion** and **ABCIVersion**.These are denoted using semantic versioning. +Changing the block protocol will require either a new major or minor release +for each of these versions as the data structures they serve have changed, +however major and minor releases wouldn't necessarily mean a block protocol change. #### RPCVersion