Final cleanup

.prettierrc.js

@@ -15,7 +15,7 @@ module.exports = {
   requirePragma: true,
   overrides: [
     {
-      files: '{docs/{,source/**},.,{gateway-js,federation-js,harmonizer,federation-integration-testsuite-js,query-planner-js,router-bridge,subgraph-js}/**,test}/{*.js,*.ts}',
+      files: '{docs/{,source/**},.,{gateway-js,harmonizer,federation-integration-testsuite-js,query-planner-js,router-bridge,subgraph-js}/**,test}/{*.js,*.ts}',
       options: {
         requirePragma: false,
         trailingComma: 'all',

DEVELOPMENT.md

@@ -11,7 +11,7 @@ Depending on the size of the release, it may be ideal to have a staging PR which
 > Note: The instructions here cater to a world where the packages in a repository are published in lock-step, as is the case with all of the `apollo-server-*` packages in the Apollo Server repository.  Release branches are still a good idea, but in this repository it quite possible that there are multiple versions involved (e.g., a version of `@apollo/federation` and a version of `@apollo/gateway`).  In that regard, it's expected that the branch names and the PR title will deviate from the suggestion below.  The branch should still be prefixed with `release-` (for _Branch protection rules_ to match easily), but the rest of the branch name might be different, e.g., `release-federation-X.Y.Z`.
 
 1. Create a branch off `main` named `release-X.Y.Z`, where `X.Y.Z` is the intended release.
-2. Edit the appropriate `CHANGELOG.md` (in the appropriate package directory; e.g., `./federation-js/CHANGELOG.md`, `./gateway-js/CHANGELOG.md`), removing the `vNEXT` section entirely.  This section will remain on `main` and be resolved during the merge.
+2. Edit the appropriate `CHANGELOG.md` (in the appropriate package directory; e.g. `./gateway-js/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:
 
    ```
@@ -31,7 +31,6 @@ Depending on the size of the release, it may be ideal to have a staging PR which
 
 There is not a root `CHANGELOG.md` on this monorepo.  Instead, there are `CHANGELOG.md` files for specific packages:
 
-- `./federation-js/CHANGELOG.md` for `@apollo/federation`
 - `./query-planner-js/CHANGELOG.md` for `@apollo/query-planner`
 - `./subgraph-js/CHANGELOG.md` for `@apollo/subgraph`
 

docs/source/api/apollo-subgraph.mdx

@@ -9,8 +9,6 @@ This API reference documents the exports from the `@apollo/subgraph` package.
 
 ## `buildSubgraphSchema`
 
-> This method previously existed in the `@apollo/federation` package and was renamed from `buildFederatedSchema` after `@apollo/federation` v0.28.0 (the previous name still works, but it might be removed in a future release).
-
 A function that takes an array of GraphQL schema modules and returns a federation-ready schema based on those modules:
 
 ```js{2}

docs/source/performance/caching.mdx

@@ -3,7 +3,7 @@ title: Server-side caching
 sidebar_title: Caching
 ---
 
-> Using cache control with Apollo Federation requires v0.1.0 of `@apollo/subgraph` (previously v0.28 of `@apollo/federation`) in your subgraph, v0.36 of `@apollo/gateway` in your router, and v3.0.2 of Apollo Server in both servers. Please note that Apollo Server's cache hints API has evolved as of v3, so be sure to review the [updated caching documentation](https://www.apollographql.com/docs/apollo-server/performance/caching/).
+> Using cache control with Apollo Federation requires at least v0.1.0 of `@apollo/subgraph` in your subgraph, v0.36 of `@apollo/gateway` in your router, and v3.0.2 of Apollo Server in both servers. Please note that Apollo Server's cache hints API has evolved as of v3, so be sure to review the [updated caching documentation](https://www.apollographql.com/docs/apollo-server/performance/caching/).
 
 ## Using cache hints with subgraphs