Merge branch 'chance/changelogs' of github.com:remix-run/remix into c…

…hance/changelogs

packages/remix-server-runtime/CHANGELOG.md

@@ -4,7 +4,7 @@
 
 ### Minor Changes
 
-- We have been busy at work [Layering Remix on top of React Router 6.4](https://github.com/remix-run/remix/blob/main/decisions/0007-remix-on-react-router-6-4-0.md) and are excited to be releasing the step 1 in this process that consists of running the server flow through a local copy the new framework agnostic `@remix-run/router`. ([#4612](https://github.com/remix-run/remix/pull/4612))
+- We have been busy at work [Layering Remix on top of React Router 6.4](https://github.com/remix-run/remix/blob/main/decisions/0007-remix-on-react-router-6-4-0.md) and are excited to be releasing step 1 in this process that consists of performing all server-side data fetches/mutations through the new framework agnostic `@remix-run/router`. Server- and client-side rendering are still done the same as before, and will be updated in subsequent releases.  ([#4612](https://github.com/remix-run/remix/pull/4612))
 - Importing functions and types from the `remix` package is deprecated, and all ([#3284](https://github.com/remix-run/remix/pull/3284))
   exported modules will be removed in the next major release. For more details,
   [see the release notes for 1.4.0](https://github.com/remix-run/remix/releases/tag/v1.4.0)
@@ -17,14 +17,14 @@
 
   Previously there was some ambiguity around _"thrown Responses go to the `CatchBoundary`"_.
   The `CatchBoundary` exists to give the _user_ a place to handle non-happy path code flows
-  such that they can throw Response instances from _their own code_ and handle them in a
+  such that they can throw `Response` instances from _their own code_ and handle them in a
   `CatchBoundary`. However, there are a handful of framework-internal errors that make
-  sense to have a non-500 status code, and the fact that these were being thrown as Responses
-  was causing them to go into the CatchBoundary, even though they were not user-thrown.
+  sense to have a non-500 status code, and the fact that these were being thrown as `Response` instances
+  was causing them to go into the `CatchBoundary`, even though they were not user-thrown.
 
   With this change, anything thrown by the framework itself (`Error` or `Response`) will
   go to the `ErrorBoundary`, and any user-thrown `Response` instances will go to the
-  `CatchBoundary`. Thereis one exception to this rule, which is that framework-detected
+  `CatchBoundary`. There is one exception to this rule, which is that framework-detected
   404's will continue to go to the `CatchBoundary` since users should have one single
   location to handle 404 displays.