-
Notifications
You must be signed in to change notification settings - Fork 8.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: the typo in docs #4865
fix: the typo in docs #4865
Conversation
Thank you, but I don't agree with most of the 2.0 to 2.x changes. In most of the occurrences stating 2.0 is more clear so that people know exactly when the change was made. If we just say 2.x it is ambiguous whether the change happened in v2.0 or in a later v2.x release. This is especially true when talking about 2.0 capabilities because the capability is actually called something like Also, when we move to v3.0, stating something is a v2.x feature won't be accurate anymore, as it implies that it is not applicable to 3.x. In these cases we should say something like "in v2.0 and higher". I'd suggest to look at each occurrence and only change the ones where there is a very compelling reason to make the change. You'll also need to add your signature to the commit to pass the DCO check. |
Signed-off-by: coderakhand <[email protected]>
@@ -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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No change needed here, the original text makes sense.
@@ -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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No change needed here, the original text makes sense.
@@ -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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No change needed here, the original text makes sense.
@@ -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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No change needed here, the original text makes sense.
@@ -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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No change needed here, the original text makes sense.
@@ -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) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No change needed here, the original text makes sense.
@@ -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: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No change needed here, the original text makes sense.
@@ -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) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No change needed here, the original text makes sense.
@@ -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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No change needed here, the original text makes sense.
@@ -1,10 +1,10 @@ | |||
# Considerations for getting to v2.x | |||
# Considerations for getting to v2.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No change needed here, the original text makes sense.
In fact, the changes proposed in this file changes the whole meaning. I'm going to go ahead and close the PR since this type of "replace all" change is not beneficial and can actually change the meaning from the original authors.
I'll close since I don't agree in general with the 2.0 to 2.x and 2.x to 2.0 changes. If you'd like to open a new pull request please squash the commits into a single commit and don't include the 2.x changes. |
Okay, sorry for any inconvenience caused by me. I am new with these things but will surely do better in next PR. |
Type of change
This PR fixes various typo in documentations.
Fixes #3271
Description