Merge pull request #423 from drewgg/patch-1

Update TN0028-change-management.mdx

src/content/technotes/TN0028-change-management.mdx

@@ -26,7 +26,7 @@ graph LR
 
 Allowing teams to independently update the components they own is a key benefit of federation. However, understanding and de-risking changes to a component can be challenging, especially because changes might require cascading changes in other components. This is especially true for GraphQL schema definitions, which must be coordinated between subgraph services and the Router.
 
-This document will cover the basic release steps that involvev changes to an existing [supergraph API](/federation/federated-types/overview). We will not go into depth on deploying changes to runtime code or the Router runtime configuration. Specifically, we'll examine two scenarios, both of which involve introducing changes to an existing federated API schema
+This document will cover the basic release steps that involve changes to an existing [supergraph API](/federation/federated-types/overview). We will not go into depth on deploying changes to runtime code or the Router runtime configuration. Specifically, we'll examine two scenarios, both of which involve introducing changes to an existing federated API schema
 
  - [Backward compatible subgraph schema changes](#backward-compatible-subgraph-schema-changes)
  - [Backward _incompatible_ subgraph schema changes](#backward-incompatible-subgraph-schema-changes)