Remove references to outdated GitLab versions

Remove references to outdated GitLab versions

Remove references to outdated GitLab versions
4589a594 · Craig Norris · 0010c6b0 · 4589a594 · 4589a594 · 4589a594
Commit 4589a594 authored Oct 14, 2021 by Craig Norris
6 changed files
--- a/doc/administration/object_storage.md
+++ b/doc/administration/object_storage.md
@@ -2,7 +2,6 @@
 stage: Enablement
 group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-type: reference
 ---

 # Object storage **(FREE SELF)**
@@ -123,8 +122,8 @@ See the section on [ETag mismatch errors](#etag-mismatch) for more details.
    gitlab_rails['object_store']['objects']['pages']['bucket'] = '<pages>'
    ```

-   For GitLab 9.4 or later, if you're using AWS IAM profiles, be sure to omit the
-   AWS access key and secret access key/value pairs. For example:
+   If you're using AWS IAM profiles, omit the AWS access key and secret access
+   key/value pairs. For example:

   ```ruby
   gitlab_rails['object_store']['connection'] = {

--- a/doc/administration/raketasks/github_import.md
+++ b/doc/administration/raketasks/github_import.md
@@ -6,8 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w

 # GitHub import **(FREE SELF)**

-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/10308) in GitLab 9.1.
-
 To retrieve and import GitHub repositories, you need a [GitHub personal access token](https://github.com/settings/tokens).
 A username should be passed as the second argument to the Rake task,
 which becomes the owner of the project. You can resume an import

--- a/doc/administration/raketasks/project_import_export.md
+++ b/doc/administration/raketasks/project_import_export.md
@@ -6,9 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w

 # Project import/export administration **(FREE SELF)**

-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/3050) in GitLab 8.9.
-> - From GitLab 11.3, import/export can use object storage automatically.
-
 GitLab provides Rake tasks relating to project import and export. For more information, see:

 - [Project import/export documentation](../../user/project/settings/import_export.md).

--- a/doc/api/sidekiq_metrics.md
+++ b/doc/api/sidekiq_metrics.md
@@ -6,8 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w

 # Sidekiq Metrics API **(FREE SELF)**

-> Introduced in GitLab 8.9.
-
 This API endpoint allows you to retrieve some information about the current state
 of Sidekiq, its jobs, queues, and processes.


--- a/doc/install/requirements.md
+++ b/doc/install/requirements.md
@@ -2,7 +2,6 @@
 stage: Enablement
 group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-type: reference
 ---

 # Installation requirements **(FREE SELF)**
@@ -119,7 +118,6 @@ the following table) as these were used for development and testing:

 | GitLab version | Minimum PostgreSQL version |
 |----------------|----------------------------|
-| 10.0           | 9.6                        |
 | 13.0           | 11                         |
 | 14.0           | 12                         |

@@ -272,9 +270,9 @@ On a very active server (10,000 billable users) the Sidekiq process can use 1GB+

 ## Prometheus and its exporters

-As of Omnibus GitLab 9.0, [Prometheus](https://prometheus.io) and its related
-exporters are enabled by default, to enable easy and in depth monitoring of
-GitLab. With default settings, these processes consume approximately 200MB of memory.
+[Prometheus](https://prometheus.io) and its related exporters are enabled by
+default to enable in depth monitoring of GitLab. With default settings, these
+processes consume approximately 200 MB of memory.

 If you would like to disable Prometheus and it's exporters or read more information
 about it, check the [Prometheus documentation](../administration/monitoring/prometheus/index.md).

--- a/doc/update/zero_downtime.md
+++ b/doc/update/zero_downtime.md
 ---
 stage: Enablement
 group: Distribution
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---

 # Zero downtime upgrades **(FREE SELF)**

-Starting with GitLab 9.1.0 it's possible to upgrade to a newer major, minor, or
-patch version of GitLab without having to take your GitLab instance offline.
-However, for this to work there are the following requirements:
+It's possible to upgrade to a newer major, minor, or patch version of GitLab
+without having to take your GitLab instance offline. However, for this to work
+there are the following requirements:

- You can only upgrade 1 minor release at a time. So from 9.1 to 9.2, not to
-   9.3. If you skip releases, database modifications may be run in the wrong
+- You can only upgrade one minor release at a time. So from 13.1 to 13.2, not to
+   13.3. If you skip releases, database modifications may be run in the wrong
   sequence [and leave the database schema in a broken state](https://gitlab.com/gitlab-org/gitlab/-/issues/321542).
 - You have to use [post-deployment migrations](../development/post_deployment_migrations.md).
 - You are using PostgreSQL. Starting from GitLab 12.1, MySQL is not supported.
@@ -36,10 +36,10 @@ to re-read any database changes that have been made by post-deployment migration

 Most of the time you can safely upgrade from a patch release to the next minor
 release if the patch release is not the latest. For example, upgrading from
-9.1.1 to 9.2.0 should be safe even if 9.1.2 has been released. We do recommend
+14.1.1 to 14.2.0 should be safe even if 14.1.2 has been released. We do recommend
 you check the release posts of any releases between your current and target
 version just in case they include any migrations that may require you to upgrade
-1 release at a time.
+one release at a time.

 Some releases may also include so called "background migrations". These
 migrations are performed in the background by Sidekiq and are often used for
@@ -63,21 +63,21 @@ the migrations that are being performed.

 To help explain this, let's look at some examples:

-**Example 1:** You are running a large GitLab installation using version 9.4.2,
-which is the latest patch release of 9.4. When GitLab 9.5.0 is released this
-installation can be safely upgraded to 9.5.0 without requiring downtime if the
-requirements mentioned above are met. You can also skip 9.5.0 and upgrade to
-9.5.1 after it's released, but you **can not** upgrade straight to 9.6.0; you
-_have_ to first upgrade to a 9.5.Z release.
-
-**Example 2:** You are running a large GitLab installation using version 9.4.2,
-which is the latest patch release of 9.4. GitLab 9.5 includes some background
-migrations, and 10.0 requires these to be completed (processing any
-remaining jobs for you). Skipping 9.5 is not possible without downtime, and due
+**Example 1:** You are running a large GitLab installation using version 13.4.2,
+which is the latest patch release of 13.4. When GitLab 13.5.0 is released this
+installation can be safely upgraded to 13.5.0 without requiring downtime if the
+requirements mentioned above are met. You can also skip 13.5.0 and upgrade to
+13.5.1 after it's released, but you **can not** upgrade straight to 13.6.0; you
+_have_ to first upgrade to a 13.5.Z release.
+
+**Example 2:** You are running a large GitLab installation using version 13.4.2,
+which is the latest patch release of 13.4. GitLab 13.5 includes some background
+migrations, and 14.0 requires these to be completed (processing any
+remaining jobs for you). Skipping 13.5 is not possible without downtime, and due
 to the background migrations would require potentially hours of downtime
 depending on how long it takes for the background migrations to complete. To
-work around this you have to upgrade to 9.5.Z first, then wait at least a
-week before upgrading to 10.0.
+work around this you have to upgrade to 13.5.Z first, then wait at least a
+week before upgrading to 14.0.

 **Example 3:** You use MySQL as the database for GitLab. Any upgrade to a new
 major/minor release requires downtime. If a release includes any background
@@ -89,7 +89,7 @@ meet the other online upgrade requirements mentioned above.

 Before following these instructions, note the following **important** information:

- You can only upgrade 1 minor release at a time. So from 13.6 to 13.7, not to 13.8.
+- You can only upgrade one minor release at a time. So from 13.6 to 13.7, not to 13.8.
  If you attempt more than one minor release, the upgrade may fail.
 - On single-node Omnibus deployments, updates with no downtime are not possible when
  using Puma because Puma always requires a complete restart. This is because the
@@ -156,7 +156,7 @@ you've completed these steps.

 ## Multi-node / HA deployment

-You can only upgrade 1 minor release at a time. So from 13.6 to 13.7, not to 13.8.
+You can only upgrade one minor release at a time. So from 13.6 to 13.7, not to 13.8.
 If you attempt more than one minor release, the upgrade may fail.

 ### Use a load balancer in front of web (Puma) nodes