Docs fixes (#7050)

- Fixed a typo
- Updated the docs to remove a mention of v4
- Removed old v3 page

website/docs/reference/impression-data.md

@@ -103,7 +103,7 @@ unleash.on('ready', () => {
 });
 
 unleash.on('impression', (event) => {
-  // Capture the event here and pass it internal data lake or analytics provider
+  // Capture the event here and pass it to internal data lake or analytics provider
   console.log(event);
 });
 ```

website/docs/using-unleash/deploy/configuring-unleash.md

@@ -4,8 +4,7 @@ title: Configuring Unleash
 
 import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem';
 
-> This is the guide on how to configure **Unleash v4 self-hosted**. If you are still using Unleash v3 you should
-> checkout [configuring Unleash v3](./configuring-unleash-v3.md)
+> This is the guide on how to configure **Unleash v5 self-hosted**.
 
 ## Must configure
 

website/docs/using-unleash/deploy/upgrading-unleash.md

@@ -137,29 +137,3 @@ In v2 you could query feature toggles on `/api/features`. This was deprecated in
 Unleash no longer ships with a binary that allows you to start Unleash directly from the command line. From v4 you need to either use Unleash via docker or programmatically.
 
 Read more in our [getting started documentation](./getting-started.md)
-
-## Upgrading from v2.x to v3.x {#upgrading-from-v2x-to-v3x}
-
-The notable change introduced in Unleash v3.x is a strict separation of API paths for client requests and admin requests. This makes it easier to implement different authentication mechanisms for the admin UI and all unleash-clients. You can read more about [securing unleash](./securing-unleash.md).
-
-The recommended approach is to first upgrade the `unleash-server` to v3 (which still supports v2 clients). After this is done, you should upgrade all your clients to v3.
-
-After upgrading all your clients, you should consider turning off legacy routes, used by v2 clients. To do this, set the configuration option `enableLegacyRoutes` to `false` as described in the [page on configuring Unleash v3](./configuring-unleash-v3.md).
-
-## Upgrading from v1.0 to v2.0 {#upgrading-from-v10-to-v20}
-
-### Caveat 1: Not used db-migrate to migrate the Unleash database? {#caveat-1-not-used-db-migrate-to-migrate-the-unleash-database}
-
-In FINN we used liquibase, for internal reasons, to migrate our database. Because unleash from version 2.0 migrates the database internally, with db-migrate, you need to make sure that all previous migrations for version 1 exist, so that Unleash does not try to create already existing tables.
-
-#### How to check? {#how-to-check}
-
-If you don't have a "migrations" table with _7 unique migrations_ you are affected by this.
-
-#### How to fix? {#how-to-fix}
-
-Before starting unleash version 2 you have to run the SQL located under `scripts/fix-migrations-version-1.sql`
-
-### Caveat 2: databaseUrl (not database*Uri*) {#caveat-2-databaseurl-not-databaseuri}
-
-Using Unleash as a library and injecting your own config? Then you should know that we changed the `databaseUri` config param name to **databaseUrl**. This is to make sure the param is aligned with the environment variable `DATABASE_URL` and avoid multiple names for the same config param.

website/docusaurus.config.js

@@ -759,13 +759,6 @@ module.exports = {
                         ],
                         to: '/using-unleash/deploy/configuring-unleash',
                     },
-                    {
-                        from: [
-                            '/reference/deploy/configuring-unleash-v3',
-                            '/deploy/configuring_unleash_v3',
-                        ],
-                        to: '/using-unleash/deploy/configuring-unleash-v3',
-                    },
                     {
                         from: [
                             '/reference/deploy/database-setup',