docs: audit grammar issues (#6203)

* docs: audit grammar mistakes

* fix code block language

* revert change

* let's get another

website/docs/guides/docs/versioning.md

@@ -18,7 +18,7 @@ To better understand how versioning works and see if it suits your needs, you ca
 
 ## Directory structure {#directory-structure}
 
-```shell
+```bash
 website
 ├── sidebars.json        # sidebar for the current docs version
 ├── docs                 # docs directory for the current docs version
@@ -54,7 +54,7 @@ The table below explains how a versioned file maps to its version and the genera
 
 The files in the `docs` directory belong to the `current` docs version.
 
-By default, the `current` docs version is labelled as `Next` and hosted under `/docs/next/*`, but is entirely configurable to fit your project's release lifecycle.
+By default, the `current` docs version is labeled as `Next` and hosted under `/docs/next/*`, but it is entirely configurable to fit your project's release lifecycle.
 
 :::
 
@@ -78,11 +78,11 @@ When tagging a new version, the document versioning mechanism will:
 ### Creating new docs {#creating-new-docs}
 
 1. Place the new file into the corresponding version folder.
-1. Include the reference for the new file into the corresponding sidebar file, according to version number.
+2. Include the reference to the new file in the corresponding sidebar file according to the version number.
 
 **Current version docs**
 
-```shell
+```bash
 # The new file.
 docs/new.md
 
@@ -92,7 +92,7 @@ sidebar.js
 
 **Older version docs**
 
-```shell
+```bash
 # The new file.
 versioned_docs/version-1.0.0/new.md
 
@@ -103,7 +103,7 @@ versioned_sidebars/version-1.0.0-sidebars.json
 ### Linking docs {#linking-docs}
 
 - Remember to include the `.md` extension.
-- Files will be linked to correct corresponding version.
+- Files will be linked to the correct corresponding version.
 - Relative paths work as well.
 
 ```md
@@ -156,9 +156,9 @@ There are different ways to manage versioning, but two very common patterns are:
 - You release v1, and start immediately working on v2 (including its docs)
 - You release v1, and will maintain it for some time before thinking about v2.
 
-Docusaurus defaults work great for the first usecase.
+Docusaurus defaults work great for the first use case.
 
-**For the 2nd usecase**: if you release v1 and don't plan to work on v2 anytime soon, instead of versioning v1 and having to maintain the docs in 2 folders (`./docs` + `./versioned_docs/version-1.0.0`), you may consider using the following configuration instead:
+**For the 2nd use case**: if you release v1 and don't plan to work on v2 anytime soon, instead of versioning v1 and having to maintain the docs in 2 folders (`./docs` + `./versioned_docs/version-1.0.0`), you may consider using the following configuration instead:
 
 ```json
 {
@@ -178,17 +178,23 @@ See [docs plugin configuration](../../api/plugins/plugin-content-docs.md) for mo
 
 ### Version your documentation only when needed {#version-your-documentation-only-when-needed}
 
-For example, you are building a documentation for your npm package `foo` and you are currently in version 1.0.0. You then release a patch version for a minor bug fix and it's now 1.0.1.
+For example, you are building documentation for your npm package `foo` and you are currently in version 1.0.0. You then release a patch version for a minor bug fix and it's now 1.0.1.
 
 Should you cut a new documentation version 1.0.1? **You probably shouldn't**. 1.0.1 and 1.0.0 docs shouldn't differ according to semver because there are no new features!. Cutting a new version for it will only just create unnecessary duplicated files.
 
 ### Keep the number of versions small {#keep-the-number-of-versions-small}
 
-As a good rule of thumb, try to keep the number of your versions below 10. **It is very likely** that you will have a lot of obsolete versioned documentation that nobody even reads anymore. For example, [Jest](https://jestjs.io/versions) is currently in version `24.9`, and only maintains several latest documentation versions with the lowest being `22.X`. Keep it small 😊
+As a good rule of thumb, try to keep the number of your versions below 10. You will **very likely** to have a lot of obsolete versioned documentation that nobody even reads anymore. For example, [Jest](https://jestjs.io/versions) is currently in version `27.4`, and only maintains several latest documentation versions with the lowest being `25.X`. Keep it small 😊
+
+:::tip archive older versions
+
+If you deploy your site on a Jamstack provider (e.g. [Netlify](../../deployment.mdx)), the provider will save each production build as a snapshot under an immutable URL. You can include archived versions that will never be rebuilt as external links to these immutable URLs. The Jest website and the Docusaurus website both use such pattern to keep the number of actively built versions low.
+
+:::
 
 ### Use absolute import within the docs {#use-absolute-import-within-the-docs}
 
-Don't use relative paths import within the docs. Because when we cut a version the paths no longer work (the nesting level is different, among other reasons). You can utilize the `@site` alias provided by Docusaurus, that points to the `website` directory. Example:
+Don't use relative paths import within the docs. Because when we cut a version the paths no longer work (the nesting level is different, among other reasons). You can utilize the `@site` alias provided by Docusaurus that points to the `website` directory. Example:
 
 ```diff
 - import Foo from '../src/components/Foo';
@@ -197,7 +203,7 @@ Don't use relative paths import within the docs. Because when we cut a version t
 
 ### Global or versioned colocated assets {#global-or-versioned-colocated-assets}
 
-You should decide if assets like images and files are per version or shared between versions
+You should decide if assets like images and files are per-version or shared between versions.
 
 If your assets should be versioned, put them in the docs version, and use relative paths: