fix: the typo in docs

core/ledger/kvledger/txmgmt/privacyenabledstate/db.go

@@ -466,7 +466,7 @@ type namespaceProvider struct {
 // existing database matches the namespace and filter out all extra namespaces if no databases match them.
 // Checking peer membership is complicated because it requires retrieving all the collection configs from
 // the collection config store. Because this is a temporary function needed to retroactively build namespaces
-// when upgrading v2.0/2.1 peers to a newer v2.x version and because returning extra private data namespaces
+// when upgrading v2.0/2.1 peers to a newer v2.0 version and because returning extra private data namespaces
 // does not cause inconsistence, it makes sense to use the simple implementation.
 func (p *namespaceProvider) PossibleNamespaces(vdb statedb.VersionedDB) ([]string, error) {
 	retNamespaces := []string{}

discovery/test/testdata/configtx.yaml

@@ -156,7 +156,7 @@ Capabilities:
     # used with prior release orderers.
     # Set the value of the capability to true to require it.
     Application: &ApplicationCapabilities
-        # V2.0 for Application enables the new non-backwards compatible
+        # v2.0 for Application enables the new non-backwards compatible
         # features and fixes of fabric v2.0.
         V2_0: true
         # V1.3 for Application enables the new non-backwards compatible

docs/source/cc_service.md

@@ -2,7 +2,7 @@
 
 **Attention: This page is for advanced users who choose to configure chaincode as a service external to the Fabric peer. Proceed with caution!** New users of chaincode should start with [deploying a smart contract to a channel](deploy_chaincode.html) before proceeding with this tutorial.
 
-Fabric v2.0 supports chaincode deployment and execution outside of Fabric that enables users to manage a chaincode runtime independently of the peer. This facilitates deployment of chaincode on Fabric cloud deployments, such as Kubernetes. Instead of building and launching the chaincode on every peer, chaincode can be run as a service, external to Fabric. This capability leverages the Fabric v2.0 external builder and launcher functionality, which enables operators to extend a peer with programs to build, launch, and discover chaincode. Before reading this topic you should become familiar with the [External Builder and Launcher](./cc_launcher.html) content.
+Fabric v2.0 and higher supports chaincode deployment and execution outside of Fabric that enables users to manage a chaincode runtime independently of the peer. This facilitates deployment of chaincode on Fabric cloud deployments, such as Kubernetes. Instead of building and launching the chaincode on every peer, chaincode can be run as a service, external to Fabric. This capability leverages the Fabric v2.0 external builder and launcher functionality, which enables operators to extend a peer with programs to build, launch, and discover chaincode. Before reading this topic you should become familiar with the [External Builder and Launcher](./cc_launcher.html) content.
 
 Prior to the availability of the external builders, the chaincode package content was required to be a set of source code files for a particular language which could be built and launched as a chaincode binary. The new external build and launcher functionality now allows users to optionally customize the build process. With respect to running the chaincode as an external service, the build process allows you to specify the endpoint information of the server where the chaincode is running. Hence the package simply consists of the externally running chaincode server endpoint information and TLS artifacts for secure connection. TLS is optional but highly recommended for all environments except a simple test environment.
 
@@ -27,8 +27,8 @@ metadata.json
 code.tar.gz
 ```
 
-The chaincode package should be used to provide two pieces of information to the external builder and launcher process
-* identify if the chaincode is an external service. The `bin/detect` section describes an approach using the `metadata.json` file
+The chaincode package should be used to provide two pieces of information to the external builder and launcher process:
+* identify if the chaincode is an external service. The `bin/detect` section describes an approach using the `metadata.json` file.
 * provide chaincode endpoint information in a `connection.json` file placed in the release directory. 
 
 There is plenty of flexibility to gathering the above information. The sample scripts in the [External builder and launcher sample scripts](#external-builder-and-launcher-sample-scripts) illustrate a simple approach to providing the information.
@@ -41,13 +41,13 @@ tar cfz myccpackage.tgz metadata.json code.tar.gz
 
 ## Configuring a peer to process external chaincode
 
-In this section we go over the configuration needed
+In this section we go over the configuration needed:
 * to detect if the chaincode package identifies an external chaincode service
 * to create the `connection.json` file in the release directory
 
 ### Modify the peer core.yaml to include the externalBuilder
 
-Assume the scripts are on the peer in the `bin` directory as follows
+Assume the scripts are on the peer in the `bin` directory as follows:
 ```
     <fully qualified path on the peer's env>
     └── bin
@@ -140,7 +140,7 @@ exit 0
 
 #### bin/release
 
-For chaincode as an external service, the `bin/release` script is responsible for providing the `connection.json` to the peer by placing it in the `RELEASE_OUTPUT_DIR`.  The `connection.json` file has the following JSON structure
+For chaincode as an external service, the `bin/release` script is responsible for providing the `connection.json` to the peer by placing it in the `RELEASE_OUTPUT_DIR`.  The `connection.json` file has the following JSON structure:
 
 * **address** - chaincode server endpoint accessible from peer. Must be specified in “<host>:<port>” format.
 * **domain** - chaincode service domain name. If the address is not authorized by the TLS certificate of the chaincode service, you can specify an authorized address through domain.

docs/source/chaincode_lifecycle.md

@@ -476,7 +476,7 @@ different chaincode definitions. As a result, both peers have two chaincode
 containers running on their peers. MYCC1 has an endorsement policy of 1 out of 2,
 while MYCC2 has an endorsement policy of 2 out of 2.*
 
-## Migrate to the v2.x Fabric lifecycle
+## Migrate to the v2.0 Fabric lifecycle
 
 For information about migrating to the new lifecycle, check out [Considerations for getting to v2.0](./upgrade_to_newest_version.html#chaincode-lifecycle).
 

docs/source/create_channel/create_channel_config.md

@@ -83,7 +83,7 @@ You can see the part of `configtx.yaml` that defines Org1 of the test network be
 
 ## Capabilities
 
-Fabric channels can be joined by orderer and peer nodes that are running different versions of Hyperledger Fabric. Channel capabilities allow organizations that are running different Fabric binaries to participate on the same channel by only enabling certain features. For example, organizations that are running Fabric v1.4 and organizations that are running Fabric v2.x can join the same channel as long as the channel capabilities levels are set to V1_4_X or below. None of the channel members will be able to use the features introduced in Fabric v2.0. Note that this is true as long as the new binaries still support a feature that existed in a previous version, and do not use a new feature that does not exist in a previous version. For example, the system channel is no longer supported in version v3.0. Thus, a v3.0 binary will not interoperate with a v2.x binary that still operates with the system channel.
+Fabric channels can be joined by orderer and peer nodes that are running different versions of Hyperledger Fabric. Channel capabilities allow organizations that are running different Fabric binaries to participate on the same channel by only enabling certain features. For example, organizations that are running Fabric v1.4 and organizations that are running Fabric v2.0 can join the same channel as long as the channel capabilities levels are set to V1_4_X or below. None of the channel members will be able to use the features introduced in Fabric v2.0. Note that this is true as long as the new binaries still support a feature that existed in a previous version, and do not use a new feature that does not exist in a previous version. For example, the system channel is no longer supported in version v3.0. Thus, a v3.0 binary will not interoperate with a v2.0 binary that still operates with the system channel.
 
 If you examine the `configtx.yaml` file, you will see three capability groups:
 
@@ -93,7 +93,7 @@ If you examine the `configtx.yaml` file, you will see three capability groups:
 
 - **Channel** capabilities set the minimum version of the Fabric that can be run by peer and ordering nodes.
 
-Because both of the peers and the ordering node of the Fabric test network run version v2.x, every capability group is set to `V2_0`. As a result, the test network cannot be joined by nodes that run a lower version of Fabric than v2.0. For more information, see the [capabilities](../capabilities_concept.html) concept topic.  
+Because both of the peers and the ordering node of the Fabric test network run version v2.0, every capability group is set to `V2_0`. As a result, the test network cannot be joined by nodes that run a lower version of Fabric than v2.0. For more information, see the [capabilities](../capabilities_concept.html) concept topic.  
 
 ## Application
 

docs/source/enable_cc_lifecycle.md

@@ -1,6 +1,6 @@
 # Enabling the new chaincode lifecycle
 
-Users upgrading from v1.4.x to v2.x will have to edit their channel configurations to enable the new lifecycle features. This process involves a series of [channel configuration updates](./config_update.html) the relevant users will have to perform.
+Users upgrading from v1.4.x to v2.0 and higher will have to edit their channel configurations to enable the new lifecycle features. This process involves a series of [channel configuration updates](./config_update.html) the relevant users will have to perform.
 
 Note that the `Channel` and `Application` [capabilities](./capabilities_concept.html) of your application channels will have to be updated to `V2_0` for the new chaincode lifecycle to work. Check out [Considerations for getting to 2.0](./upgrade_to_newest_version.html#chaincode-lifecycle) for more information.
 

docs/source/gateway.md

@@ -40,7 +40,7 @@ Hyperledger Fabric currently supports client application development in three la
 
 In order for a transaction to be successfully committed to the ledger, a sufficient number of endorsements are required in order to satisfy
 the [endorsement policy](endorsement-policies.html). Getting an endorsement from an organization involves connecting to one
-of its peers and have it simulate (execute) the transaction proposal against its copy of the ledger. The peer simulates the transaction by invoking the chaincode function, as specified by its name and arguments in the proposal, and building (and signing) a read-write set. The read-write set contains the current ledger state and proposed changes in response to the state get/set instructions in that function.
+of its peers and having it simulate (execute) the transaction proposal against its copy of the ledger. The peer simulates the transaction by invoking the chaincode function, as specified by its name and arguments in the proposal, and building (and signing) a read-write set. The read-write set contains the current ledger state and proposed changes in response to the state get/set instructions in that function.
 
 The endorsement policy, or sum of multiple policies, that gets applied to a transaction depends on the implementation of the chaincode function that is being invoked, and could be a combination of the following:
 

docs/source/international_languages.md

@@ -230,7 +230,7 @@ order of translation in your workgroup.
 
 
 * [What's new in Hyperledger Fabric
-  v2.x](https://hyperledger-fabric.readthedocs.io/en/{BRANCH_DOC}/whatsnew.html)
+  v2.0](https://hyperledger-fabric.readthedocs.io/en/{BRANCH_DOC}/whatsnew.html)
 
   This topic covers the latest features in Hyperledger Fabric.
 

docs/source/orderer/ordering_service.md

@@ -203,9 +203,9 @@ implementation the node will be used in), check out [our documentation on deploy
   up to and not including a third of the parties running the orderers may not be trusted due to malicious intent or being compromised.
 
 * **Kafka**
-  Kafka was deprecated in v2.x and is no longer supported in v3.x
+  Kafka was deprecated in v2.0 and is no longer supported in v3.x
 
-* **Solo** (deprecated in v2.x)
+* **Solo** (deprecated in v2.0)
 
   The Solo implementation of the ordering service is intended for test only and
   consists only of a single ordering node. It has been deprecated and may be

docs/source/performance.md

@@ -247,7 +247,7 @@ Ensure monitoring of resources used by CouchDB instances, because as the size of
 
 ### CouchDB cache
 
-When using an external CouchDB state database, read delays during the endorsement and validation transaction phases have shown to be a performance bottleneck. In Fabric v2.x, the peer cache replaces many of these expensive lookups with fast local cache reads.
+When using an external CouchDB state database, read delays during the endorsement and validation transaction phases have shown to be a performance bottleneck. In Fabric v2.0, the peer cache replaces many of these expensive lookups with fast local cache reads.
 
 The cache will not improve performance of JSON queries.
 

docs/source/prereqs.md

@@ -39,7 +39,7 @@ curl --version # => curl 7.64.1 (...)
 Install the latest version of [Docker Desktop](https://docs.docker.com/get-docker/) if it is not already installed.
 Since Docker Desktop is a UI application on Mac, use `cask` to install it.
 
-Homebrew v2.x:
+Homebrew v2.0:
 
 ```shell
 brew cask install --appdir="/Applications" docker

docs/source/test_network.md

@@ -52,7 +52,7 @@ Usage:
     Flags:
     Used with network.sh up, network.sh createChannel:
     -ca - Use Certificate Authorities to generate network crypto material
-    -bft - Use Orderers with consensus type BFT (Not available in Fabric v2.x)
+    -bft - Use Orderers with consensus type BFT (Not available in Fabric v2.0)
     -c <channel name> - Name of channel to create (defaults to "mychannel")
     -s <dbtype> - Peer state database to deploy: goleveldb (default) or couchdb
     -r <max retry> - CLI times out after certain number of attempts (defaults to 5)

docs/source/upgrade.rst

@@ -27,7 +27,7 @@ tutorials:
    version before updating any capabilities.
 3. :doc:`updating_capabilities`. Completed after updating the versions of all nodes.
 4. :doc:`enable_cc_lifecycle`. Necessary to add organization specific endorsement
-   policies central to the new chaincode lifecycle for Fabric v2.x.
+   policies central to the new chaincode lifecycle for Fabric v2.0.
 
 As the upgrading of nodes and increasing the capability levels of channels is by
 now considered a standard Fabric process, we will not show the specific commands