Update "master" branch references to "main".

Update "master" branch references to "main".

Signed-off-by: David Enyeart <enyeart@us.ibm.com>
(cherry picked from commit 54e27a6)

.github/settings.yml

@@ -10,7 +10,7 @@ repository:
     a unique approach to consensus that enables performance at scale while preserving
     privacy.
   homepage: https://wiki.hyperledger.org/display/fabric
-  default_branch: master
+  default_branch: main
   has_downloads: true
   has_issues: false
   has_projects: false

README.md

@@ -3,7 +3,7 @@
 [rocketchat-url]: https://chat.hyperledger.org/channel/fabric
 [rocketchat-image]: https://open.rocket.chat/images/join-chat.svg
 
-[![Build Status](https://dev.azure.com/Hyperledger/Fabric/_apis/build/status/Merge?branchName=master)](https://dev.azure.com/Hyperledger/Fabric/_build/latest?definitionId=51&branchName=master)
+[![Build Status](https://dev.azure.com/Hyperledger/Fabric/_apis/build/status/Merge?branchName=main)](https://dev.azure.com/Hyperledger/Fabric/_build/latest?definitionId=51&branchName=main)
 [![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/955/badge)](https://bestpractices.coreinfrastructure.org/projects/955)
 [![Go Report Card](https://goreportcard.com/badge/github.com/hyperledger/fabric)](https://goreportcard.com/report/github.com/hyperledger/fabric)
 [![GoDoc](https://godoc.org/github.com/hyperledger/fabric?status.svg)](https://godoc.org/github.com/hyperledger/fabric)
@@ -28,7 +28,7 @@ Fabric provides a release approximately once every four months with new features
 and improvements. Additionally, certain releases are designated as long-term
 support (LTS) releases. Important fixes will be backported to the most recent
 LTS release, and to the prior LTS release during periods of LTS release overlap.
-For more details see the [LTS strategy](https://github.com/hyperledger/fabric-rfcs/blob/master/text/0005-lts-release-strategy.md).
+For more details see the [LTS strategy](https://github.com/hyperledger/fabric-rfcs/blob/main/text/0005-lts-release-strategy.md).
 
 LTS releases:
 - [v2.2.x](https://hyperledger-fabric.readthedocs.io/en/release-2.2/whatsnew.html) (current LTS release)
@@ -56,7 +56,7 @@ information on getting started using and developing with the fabric, SDK and cha
 - [v1.2](http://hyperledger-fabric.readthedocs.io/en/release-1.2/)
 - [v1.1](http://hyperledger-fabric.readthedocs.io/en/release-1.1/)
 - [v1.0](http://hyperledger-fabric.readthedocs.io/en/release-1.0/)
-- [master branch (development)](http://hyperledger-fabric.readthedocs.io/en/master/)
+- [main branch (development)](http://hyperledger-fabric.readthedocs.io/en/latest/)
 
 It's recommended for first-time users to begin by going through the Getting Started section of the documentation in order to gain familiarity with the Hyperledger Fabric components and the basic transaction flow.
 

ci/azure-pipelines-merge.yml

@@ -4,7 +4,7 @@
 
 name: $(SourceBranchName)-$(Date:yyyyMMdd)$(Rev:.rrr)
 trigger:
-- master
+- main
 - release-2.*
 pr: none
 

ci/azure-pipelines.yml

@@ -5,7 +5,7 @@
 name: $(SourceBranchName)-$(Date:yyyyMMdd)$(Rev:.rrr)
 trigger: none
 pr:
-- master
+- main
 - release-2.*
 
 variables:

docs/source/CONTRIBUTING.rst

@@ -112,7 +112,7 @@ approved.
 Maintainers
 ~~~~~~~~~~~
 
-The Fabric project is lead by the project's top level `maintainers <https://github.com/hyperledger/fabric/blob/master/MAINTAINERS.md>`__.
+The Fabric project is lead by the project's top level `maintainers <https://github.com/hyperledger/fabric/blob/main/MAINTAINERS.md>`__.
 The maintainers are responsible for reviewing and merging all patches submitted
 for review, and they guide the overall technical direction of the project within
 the guidelines established by the Hyperledger Technical Steering Committee (TSC).
@@ -128,7 +128,7 @@ adding a maintainer, based on the following criteria:
 - Demonstrated shepherding of project work and contributors
 
 An existing maintainer can submit a pull request to the
-`maintainers <https://github.com/hyperledger/fabric/blob/master/MAINTAINERS.md>`__ file.
+`maintainers <https://github.com/hyperledger/fabric/blob/main/MAINTAINERS.md>`__ file.
 A nominated Contributor may become a Maintainer by a majority approval of the proposal
 by the existing Maintainers. Once approved, the change set is then merged
 and the individual is added to the maintainers group.
@@ -148,7 +148,7 @@ Releases
 Fabric provides a release approximately once every four months with new features and improvements.
 New feature work is merged to the Fabric main branch on `GitHub <https://github.com/hyperledger/fabric>`__.
 Releases branches are created prior to each release so that the code can stabilize while
-new features continue to get merged to the master branch.
+new features continue to get merged to the main branch.
 Important fixes will also be backported to the most recent LTS (long-term support) release branch,
 and to the prior LTS release branch during periods of LTS release overlap.
 
@@ -402,12 +402,12 @@ Legal stuff
 
 **Note:** Each source file must include a license header for the Apache
 Software License 2.0. See the template of the `license header
-<https://github.com/hyperledger/fabric/blob/master/docs/source/dev-setup/headers.txt>`__.
+<https://github.com/hyperledger/fabric/blob/main/docs/source/dev-setup/headers.txt>`__.
 
 We have tried to make it as easy as possible to make contributions. This
 applies to how we handle the legal aspects of contribution. We use the
 same approach—the `Developer's Certificate of Origin 1.1
-(DCO) <https://github.com/hyperledger/fabric/blob/master/docs/source/DCO1.1.txt>`__—that the Linux® Kernel
+(DCO) <https://github.com/hyperledger/fabric/blob/main/docs/source/DCO1.1.txt>`__—that the Linux® Kernel
 `community <https://elinux.org/Developer_Certificate_Of_Origin>`__ uses
 to manage code contributions.
 

docs/source/chaincode4ade.rst

@@ -332,7 +332,7 @@ return all of the assets on the ledger.
           to keep this tutorial as clear and straightforward as possible. In a
           real-world implementation, it is likely that packages will be segmented
           where a ``main`` package imports the chaincode package to allow for easy unit testing.
-          To see what this looks like, see the asset-transfer `Go chaincode <https://github.com/hyperledger/fabric-samples/tree/master/asset-transfer-basic/chaincode-go>`__
+          To see what this looks like, see the asset-transfer `Go chaincode <https://github.com/hyperledger/fabric-samples/tree/main/asset-transfer-basic/chaincode-go>`__
           in fabric-samples. If you look at ``assetTransfer.go``, you will see that
           it contains ``package main`` and imports ``package chaincode`` defined in ``smartcontract.go`` and
           located at ``fabric-samples/asset-transfer-basic/chaincode-go/chaincode/``.

docs/source/conf.py

@@ -83,9 +83,9 @@
 # built documents.
 #
 # The short X.Y version.
-version = u'master'
+version = u'main'
 # The full version, including alpha/beta/rc tags.
-release = u'master'
+release = u'main'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.

docs/source/couchdb_as_state_database.rst

@@ -69,7 +69,7 @@ the state database and model assets as JSON in chaincode, you can perform JSON q
 the data in the state database by using the ``GetQueryResult`` API and passing a CouchDB query string.
 The query string follows the `CouchDB JSON query syntax <http://docs.couchdb.org/en/2.1.1/api/database/find.html>`__.
 
-The `asset transfer Fabric sample <https://github.com/hyperledger/fabric-samples/blob/master/asset-transfer-ledger-queries/chaincode-go/asset_transfer_ledger_chaincode.go>`__
+The `asset transfer Fabric sample <https://github.com/hyperledger/fabric-samples/blob/main/asset-transfer-ledger-queries/chaincode-go/asset_transfer_ledger_chaincode.go>`__
 demonstrates use of CouchDB queries from chaincode. It includes a ``queryAssetsByOwner()`` function
 that demonstrates parameterized queries by passing an owner id into chaincode. It then queries the
 state data for JSON documents matching the docType of "asset" and the owner id using the JSON query
@@ -140,7 +140,7 @@ fields is provided:
 
   {"index":{"fields":["docType","owner"]},"ddoc":"indexOwnerDoc", "name":"indexOwner","type":"json"}
 
-The sample index can be found `here <https://github.com/hyperledger/fabric-samples/blob/master/asset-transfer-ledger-queries/chaincode-go/META-INF/statedb/couchdb/indexes/indexOwner.json>`__.
+The sample index can be found `here <https://github.com/hyperledger/fabric-samples/blob/main/asset-transfer-ledger-queries/chaincode-go/META-INF/statedb/couchdb/indexes/indexOwner.json>`__.
 
 Any index in the chaincode’s ``META-INF/statedb/couchdb/indexes`` directory
 will be packaged up with the chaincode for deployment. The index will be deployed

docs/source/deployment_guide_overview.rst

@@ -142,7 +142,7 @@ If you’ve read through the key concept topic on :doc:`peers/peers`, you should
 
 These roles are important to understand before you create a peer, as they will influence your customization and deployment decisions. For a look at the various decisions you will need to make, check out :doc:`deploypeer/peerplan`.
 
-The configuration values in a peer's ``core.yaml`` file must be customized or overridden with environment variables. You can find the default ``core.yaml`` configuration file `in the sampleconfig directory of Hyperledger Fabric <https://github.com/hyperledger/fabric/blob/master/sampleconfig/core.yaml>`_. This configuration file is bundled with the peer image and is also included with the downloadable binaries. For information about how to download the production ``core.yaml`` along with the peer image, check out :doc:`deploypeer/peerdeploy`.
+The configuration values in a peer's ``core.yaml`` file must be customized or overridden with environment variables. You can find the default ``core.yaml`` configuration file `in the sampleconfig directory of Hyperledger Fabric <https://github.com/hyperledger/fabric/blob/main/sampleconfig/core.yaml>`_. This configuration file is bundled with the peer image and is also included with the downloadable binaries. For information about how to download the production ``core.yaml`` along with the peer image, check out :doc:`deploypeer/peerdeploy`.
 
 While there are many parameters in the default ``core.yaml``, you will only need to customize a small percentage of them. In general, if you do not have the need to change a tuning value, keep the default value.
 
@@ -177,7 +177,7 @@ If you’ve read through the key concept topic on :doc:`orderer/ordering_service
 
 These roles are important to understand before you create an ordering service, as it will influence your customization and deployment decisions. Among the chief differences between a peer and ordering service is that in a production network, multiple ordering nodes work together to form the “ordering service” of a channel. This creates a series of important decisions that need to be made at both the node level and at the cluster level. Some of these cluster decisions are not made in individual ordering node ``orderer.yaml`` files but instead in the ``configtx.yaml`` file that is used to generate the genesis block for the system channel (which is used to bootstrap ordering nodes), and also used to generate the genesis block of application channels. For a look at the various decisions you will need to make, check out :doc:`deployorderer/ordererplan`.
 
-The configuration values in an ordering node’s ``orderer.yaml`` file must be customized or overridden with environment variables. You can find the default ``orderer.yaml`` configuration file `in the sampleconfig directory of Hyperledger Fabric <https://github.com/hyperledger/fabric/blob/master/sampleconfig/orderer.yaml>`_.
+The configuration values in an ordering node’s ``orderer.yaml`` file must be customized or overridden with environment variables. You can find the default ``orderer.yaml`` configuration file `in the sampleconfig directory of Hyperledger Fabric <https://github.com/hyperledger/fabric/blob/main/sampleconfig/orderer.yaml>`_.
 
 This configuration file is bundled with the orderer image and is also included with the downloadable binaries. For information about how to download the production ``orderer.yaml`` along with the orderer image, check out :doc:`deployorderer/ordererdeploy`.
 

docs/source/dev-setup/build.rst

@@ -72,7 +72,7 @@ Running Node.js Client SDK Unit Tests
 You must also run the Node.js unit tests to ensure that the Node.js
 client SDK is not broken by your changes. To run the Node.js unit tests,
 follow the instructions
-`here <https://github.com/hyperledger/fabric-sdk-node/blob/master/README.md>`__.
+`here <https://github.com/hyperledger/fabric-sdk-node/blob/main/README.md>`__.
 
 Configuration
 -------------

docs/source/dev-setup/devenv.rst

@@ -153,7 +153,7 @@ few commands.
 
 If those commands completely successfully, you're ready to Go!
 
-If you plan to use the Hyperledger Fabric application SDKs then be sure to check out their prerequisites in the Node.js SDK `README <https://github.com/hyperledger/fabric-sdk-node#build-and-test>`__ and Java SDK `README <https://github.com/hyperledger/fabric-gateway-java/blob/master/README.md>`__.
+If you plan to use the Hyperledger Fabric application SDKs then be sure to check out their prerequisites in the Node.js SDK `README <https://github.com/hyperledger/fabric-sdk-node#build-and-test>`__ and Java SDK `README <https://github.com/hyperledger/fabric-gateway-java/blob/main/README.md>`__.
 
 .. Licensed under Creative Commons Attribution 4.0 International License
    https://creativecommons.org/licenses/by/4.0/

docs/source/docs_guide.md

@@ -96,17 +96,17 @@ fabric/docs
 ```
 
 Spend a little time navigating the [docs
-folder](https://github.com/hyperledger/fabric/tree/master/docs) in the
+folder](https://github.com/hyperledger/fabric/tree/main/docs) in the
 Hyperledger Fabric repository. Click on the following links to see how different
 source files map to their corresponding published topics.
 
-* [`/docs/source/index.rst`](https://raw.githubusercontent.com/hyperledger/fabric/master/docs/source/index.rst) maps to [Hyperledger Fabric title page](https://hyperledger-fabric.readthedocs.io/en/{RTD_TAG}/)
+* [`/docs/source/index.rst`](https://raw.githubusercontent.com/hyperledger/fabric/main/docs/source/index.rst) maps to [Hyperledger Fabric title page](https://hyperledger-fabric.readthedocs.io/en/{RTD_TAG}/)
 
-* [`/docs/source/developapps/developing-applications.rst`](https://raw.githubusercontent.com/hyperledger/fabric/master/docs/source/developapps/developing_applications.rst)
+* [`/docs/source/developapps/developing-applications.rst`](https://raw.githubusercontent.com/hyperledger/fabric/main/docs/source/developapps/developing_applications.rst)
   maps to [Developing
   applications](https://hyperledger-fabric.readthedocs.io/en/{RTD_TAG}/developapps/developing_applications.html)
 
-* [`/docs/source/peers/peers.md`](https://raw.githubusercontent.com/hyperledger/fabric/master/docs/source/peers/peers.md)
+* [`/docs/source/peers/peers.md`](https://raw.githubusercontent.com/hyperledger/fabric/main/docs/source/peers/peers.md)
   maps to
   [Peers](https://hyperledger-fabric.readthedocs.io/en/{RTD_TAG}/peers/peers.html)
 
@@ -289,11 +289,11 @@ Japanese translation must be approved by a Japanese maintainer, and so on. You
 can find the maintainers listed in the following `CODEOWNERS` files:
 
 * US English
-  [`CODEOWNERS`](https://github.com/hyperledger/fabric/blob/master/CODEOWNERS)
+  [`CODEOWNERS`](https://github.com/hyperledger/fabric/blob/main/CODEOWNERS)
   and their [maintainer GitHub
   IDs](https://github.com/orgs/hyperledger/teams/fabric-core-doc-maintainers)
 * International language
-  [`CODEOWNERS`](https://github.com/hyperledger/fabric-docs-i18n/blob/master/CODEOWNERS)
+  [`CODEOWNERS`](https://github.com/hyperledger/fabric-docs-i18n/blob/main/CODEOWNERS)
   and their [maintainer GitHub
   IDs](https://github.com/orgs/hyperledger/teams/fabric-contributors)
 

docs/source/github/github.rst

@@ -93,22 +93,22 @@ the GitHub repository. To create a feature branch, perform the following steps:
 
 .. code::
 
-   git checkout -t origin/master
+   git checkout -t origin/main
 
-- Merge the upstream counterpart into your local master
+- Merge the upstream counterpart into your local main
 
 .. code::
 
-   git merge upstream/master
+   git merge upstream/main
 
-- Update your fork on GitHub with any changes from the upstream master
+- Update your fork on GitHub with any changes from the upstream main
 
 .. code::
 
-   git push origin master
+   git push origin main
 
 - You can now checkout a new local feature branch, this ensures you do not diverge
-  the local master branch from its remote counterpart. The feature branch will be
+  the local main branch from its remote counterpart. The feature branch will be
   an exact copy of the branch from which you created it.
 
 .. code::
@@ -258,7 +258,7 @@ will be re-triggered.
 Cherry-picking your PR to other branches
 ----------------------------------------
 
-After your PR is merged into the master branch, you need to consider whether it should be backported to earlier branches.
+After your PR is merged into the main branch, you need to consider whether it should be backported to earlier branches.
 If the content is a new feature designated for the next release, obviously backporting is not appropriate. But if it is a fix or
 update to an existing topic, don't forget to cherry-pick the PR back to earlier branches as needed.
 When in doubt, consult the maintainer that merged the PR for advice.
@@ -273,9 +273,9 @@ Replace ``2.0`` with the branch that you want to backport to. If there are no me
 a new PR is automatically generated in that branch that still requires the normal approval process to be merged.
 Remember to add a comment to the original PR for each branch that you want to backport to.
 
-If there are merge conflicts, use the GitHub ``cherry-pick`` command instead, by providing the ``SHA`` from the commit in the master branch.
+If there are merge conflicts, use the GitHub ``cherry-pick`` command instead, by providing the ``SHA`` from the commit in the main branch.
 
-- The following example shows how to cherry-pick a commit from the master branch into the release-2.0 branch:
+- The following example shows how to cherry-pick a commit from the main branch into the release-2.0 branch:
 
 .. code::
 
@@ -288,12 +288,12 @@ If there are merge conflicts, use the GitHub ``cherry-pick`` command instead, by
   git pull upstream release-2.0
   git push origin release-2.0
 
-- Create a new local branch to cherry-pick the content to and then cherry-pick the content by providing the SHA from the master branch.
+- Create a new local branch to cherry-pick the content to and then cherry-pick the content by providing the SHA from the main branch.
 
 .. code::
 
   git checkout -b <my2.0branch>
-  git cherry-pick <SHA from master branch>
+  git cherry-pick <SHA from main branch>
 
 - Resolve any merge conflicts and then push to your local branch.
 
@@ -324,17 +324,17 @@ Syncing Your Fork With the Upstream Repository
 As your development progresses, invariably new commits will be merged into the original
 project from which your forked repo was generated from. To avoid surprise merge conflicts
 you should integrate these changes into your local repository. To integrate changes
-from the upstream repository, assuming you are working on changes to the master branch,
+from the upstream repository, assuming you are working on changes to the main branch,
 execute the following commands from the root of your repository:
 
 .. code::
 
    git fetch upstream
-   git rebase upstream/master
+   git rebase upstream/main
 
 Syncing your fork only updates your local repository, you will need to push these
 updates to your forked repository to save them using the following command:
 
 .. code::
 
-   git push origin master
+   git push origin main