Update URLs to use new default branch name (i.e., main).

Author: abernix

.github/APOLLO_RELEASE_TEMPLATE.md

@@ -4,8 +4,8 @@ As with [release PRs in the past](https://github.com/apollographql/apollo-server
 
 Check the appropriate milestone (to the right) for more details on what we hope to get into this release!
 
-The intention of these release branches is to gather changes which are intended to land in a specific version (again, indiciated by the subject of this PR).  Release branches allow additional clarity into what is being staged, provide a forum for comments from the community pertaining to the release's stability, and to facilitate the creation of pre-releases (e.g. `alpha`, `beta`, `rc`) without affecting the `master` branch.
+The intention of these release branches is to gather changes which are intended to land in a specific version (again, indiciated by the subject of this PR).  Release branches allow additional clarity into what is being staged, provide a forum for comments from the community pertaining to the release's stability, and to facilitate the creation of pre-releases (e.g. `alpha`, `beta`, `rc`) without affecting the `main` branch.
 
-PRs for new features might be opened against or re-targeted to this branch by the project maintainers.  The `master` branch may be periodically merged into this branch up until the point in time that this branch is being prepared for release.  Depending on the size of the release, this may be once it reaches RC (release candidate) stage with an `-rc.x` release suffix.  Some less substantial releases may be short-lived and may never have pre-release versions.
+PRs for new features might be opened against or re-targeted to this branch by the project maintainers.  The `main` branch may be periodically merged into this branch up until the point in time that this branch is being prepared for release.  Depending on the size of the release, this may be once it reaches RC (release candidate) stage with an `-rc.x` release suffix.  Some less substantial releases may be short-lived and may never have pre-release versions.
 
-When this version is officially released onto the `latest` npm tag, this PR will be merged into `master`.
+When this version is officially released onto the `latest` npm tag, this PR will be merged into `main`.

.github/ISSUE_TEMPLATE.md

@@ -4,17 +4,17 @@
           or discuss it on our Spectrum.chat community (https://spectrum.chat/apollo).
 * 💡 Feature requests?
           Please search for an existing feature request before opening a new one.
-          If there is an existing feature request, use the 👍 to show your support 
-          for it.  If the specifics of your use case are not covered in the existing 
-          conversation, please take the time to *add new conversation* which helps 
+          If there is an existing feature request, use the 👍 to show your support
+          for it.  If the specifics of your use case are not covered in the existing
+          conversation, please take the time to *add new conversation* which helps
           move the feature's design forward.
 * ❗️ Bug?
           This is the right place! 😄
 
 Before reporting a bug, please check for existing or closed issues
 first and read the instructions for filing a bug report:
 
-https://github.com/apollographql/apollo-server/blob/master/CONTRIBUTING.md#reporting-bugs
+https://github.com/apollographql/apollo-server/blob/main/CONTRIBUTING.md#reporting-bugs
 
 ### This bug report should include:
 

.github/PULL_REQUEST_TEMPLATE.md

@@ -24,7 +24,7 @@ Here are some important details to follow:
           please _try_ to add a test which verifies the fix.  If you cannot, you should
           still submit the PR but we may still ask you (and help you!) to create a test.
 * 📖 Contribution guidelines
-          Follow https://github.com/apollographql/apollo-server/blob/master/CONTRIBUTING.md
+          Follow https://github.com/apollographql/apollo-server/blob/main/CONTRIBUTING.md
           when submitting a pull request.  Make sure existing tests still pass, and add
           tests for all new behavior.
 * ✏️ Explain your pull request

CHANGELOG.md

@@ -2,8 +2,8 @@
 
 The version headers in this history reflect the versions of Apollo Server itself.  Versions of other packages (e.g. which are not actual HTTP integrations; packages not prefixed with `apollo-server`) may use different versions.  For more details, check the publish commit for that version in the Git history, or check the individual CHANGELOGs for specific packages which are maintained separately:
 
-- [__CHANGELOG for `@apollo/gateway`__](https://github.com/apollographql/apollo-server/blob/master/packages/apollo-gateway/CHANGELOG.md)
-- [__CHANGELOG for `@apollo/federation`__](https://github.com/apollographql/apollo-server/blob/master/packages/apollo-federation/CHANGELOG.md)
+- [__CHANGELOG for `@apollo/gateway`__](https://github.com/apollographql/apollo-server/blob/main/packages/apollo-gateway/CHANGELOG.md)
+- [__CHANGELOG for `@apollo/federation`__](https://github.com/apollographql/apollo-server/blob/main/packages/apollo-federation/CHANGELOG.md)
 
 ### vNEXT
 

DEVELOPMENT.md

@@ -8,8 +8,8 @@ For now, this will be a collection of tips and tricks for the maintainers of the
 
 Depending on the size of the release, it may be ideal to have a staging PR which gathers the various features we're intending on releasing into the version.  This can be a great way for the community to understand the scope of a release and a clear way for maintainers to publicize it and gather feedback.
 
-1. Create a branch off `master` named `release-X.Y.Z`, where `X.Y.Z` is the intended release.
-2. Edit the `CHANGELOG.md`, removing the `vNEXT` section entirely.  This section will remain on `master` and be resolved during the merge.
+1. Create a branch off `main` named `release-X.Y.Z`, where `X.Y.Z` is the intended release.
+2. Edit the `CHANGELOG.md`, removing the `vNEXT` section entirely.  This section will remain on `main` and be resolved during the merge.
 3. Add a new section for `### vX.Y.Z` with a bullet indicating that something is coming soon:
 
    ```
@@ -18,9 +18,9 @@ Depending on the size of the release, it may be ideal to have a staging PR which
    - Nothing yet! Stay tuned.
    ```
 
-4. Commit this change so GitHub will allow a PR to be opened against `master` with a notable change.  A suggested commit message is `Prepare CHANGELOG.md for upcoming vX.Y.Z release.`
+4. Commit this change so GitHub will allow a PR to be opened against `main` with a notable change.  A suggested commit message is `Prepare CHANGELOG.md for upcoming vX.Y.Z release.`
 5. Push the branch to GitHub
-6. On GitHub, open a PR from the new release branch which targets `master`.
+6. On GitHub, open a PR from the new release branch which targets `main`.
    __For the title of the PR__, use "Release X.Y.Z".  __For the body,__ use the contents of the template in the `.github/APOLLO_RELEASE_TEMPLATE.md` file in this repository.  Adjust the body as you see necessary.
 
 ## Publishing a release

docs/gatsby-config.js

@@ -19,7 +19,7 @@ module.exports = {
           null: [
             'index',
             'getting-started',
-            '[Changelog](https://github.com/apollographql/apollo-server/blob/master/CHANGELOG.md)',
+            '[Changelog](https://github.com/apollographql/apollo-server/blob/main/CHANGELOG.md)',
           ],
           'Defining a Schema': [
             'schema/schema',

docs/source/api/apollo-gateway.mdx

@@ -61,7 +61,7 @@ example of using `ApolloGateway`, see [The gateway](/federation/gateway/).
 
     If you provide this function, `ApolloGateway` calls it for every
     implementing service in your data graph. The function must return an object
-    that implements the [`GraphQLDataSource` interface](https://github.com/apollographql/apollo-server/blob/master/packages/apollo-gateway/src/datasources/types.ts), such as an instance of [RemoteGraphQLDataSource](#remotegraphqldatasource) or a subclass of it.
+    that implements the [`GraphQLDataSource` interface](https://github.com/apollographql/apollo-server/blob/570f548b88/packages/apollo-gateway/src/datasources/types.ts), such as an instance of [RemoteGraphQLDataSource](#remotegraphqldatasource) or a subclass of it.
 
     The example below demonstrates adding an `x-user-id`
     HTTP header to every request the gateway sends to an implementing service:

docs/source/data/resolvers.mdx

@@ -358,7 +358,7 @@ Resolver functions take the following positional arguments, in order:
 | `parent` | <p>The return value of the resolver for this field's parent (i.e., the previous resolver in the [resolver chain](#resolver-chains)).</p><p>For resolvers of top-level fields with no parent (such as fields of `Query`), this value is obtained from the `rootValue` function passed to [Apollo Server's constructor](/api/apollo-server/#apolloserver).</p>  |
 | `args` |  <p>An object that contains all GraphQL arguments provided for this field.</p><p> For example, when executing `query{ user(id: "4") }`, the `args` object passed to the `user` resolver is `{ "id": "4" }`.</p> |
 | `context` | <p>An object shared across all resolvers that are executing for a particular operation. Use this to share per-operation state, including authentication information, dataloader instances, and anything else to track across resolvers. </p><p>See [The `context` argument](#the-context-argument) for more information.</p> |
-| `info` | <p>Contains information about the operation's execution state, including the field name, the path to the field from the root, and more. </p><p>Its core fields are listed in the [GraphQL.js source code](https://github.com/graphql/graphql-js/blob/master/src/type/definition.js#L917-L928), and it is extended with additional functionality by other modules, like [`apollo-cache-control`](https://github.com/apollographql/apollo-server/tree/master/packages/apollo-cache-control).</p> |
+| `info` | <p>Contains information about the operation's execution state, including the field name, the path to the field from the root, and more. </p><p>Its core fields are listed in the [GraphQL.js source code](https://github.com/graphql/graphql-js/blob/master/src/type/definition.js#L917-L928), and it is extended with additional functionality by other modules, like [`apollo-cache-control`](https://github.com/apollographql/apollo-server/tree/570f548b887/packages/apollo-cache-control).</p> |
 
 ### The `context` argument
 

docs/source/data/subscriptions.md

@@ -247,6 +247,6 @@ The Apollo Server implementation of `PubSub` can be replaced by another implemen
 - [Kafka](https://github.com/ancashoria/graphql-kafka-subscriptions)
 - [Postgres](https://github.com/GraphQLCollege/graphql-postgres-subscriptions)
 - [Google Cloud Firestore](https://github.com/MrBoolean/graphql-firestore-subscriptions)
-- [Add your implementation...](https://github.com/apollographql/apollo-server/pull/new/master)
+- [Add your implementation...](https://github.com/apollographql/apollo-server/pull/new/main)
 
 You can implement a `PubSub` of your own, using the exported `PubSubEngine` interface from `apollo-server` or another integration. If you want to set up a GraphQL server using the `graphql-subscriptions` package (not recommended for production), follow [this guide](https://www.apollographql.com/docs/graphql-subscriptions/).

docs/source/federation/metrics.md

@@ -26,7 +26,7 @@ These options will cause the Apollo gateway to collect tracing information from
 
 > NOTE: this section details how the gateway communicates with federated services around encoded tracing information and is not necessary to understand in order to enable federated tracing.
 
-The Apollo gateway looks to the `extensions` field of all service responses for the presence of an `ftv1` field. This field contains a representation of the tracing information for the sub-query that was executed against the service, sent as the Base64 encoding of the [protobuf representation](https://github.com/apollographql/apollo-server/blob/master/packages/apollo-engine-reporting-protobuf/src/reports.proto) of the trace. In order to request this information of federated services, the gateway will send the header pair `'apollo-federation-include-trace': 'ftv1'` on fetches if configured to collect metrics, as per above. By default a federated Apollo Server service will recognize this header pair and attach tracing information in extensions of the response.
+The Apollo gateway looks to the `extensions` field of all service responses for the presence of an `ftv1` field. This field contains a representation of the tracing information for the sub-query that was executed against the service, sent as the Base64 encoding of the [protobuf representation](https://github.com/apollographql/apollo-server/blob/main/packages/apollo-engine-reporting-protobuf/src/reports.proto) of the trace. In order to request this information of federated services, the gateway will send the header pair `'apollo-federation-include-trace': 'ftv1'` on fetches if configured to collect metrics, as per above. By default a federated Apollo Server service will recognize this header pair and attach tracing information in extensions of the response.
 
 ## How traces are constructed and aggregated