diff --git a/doc/administration/object_storage.md b/doc/administration/object_storage.md
index 6c77576cb27e22709cb6d1d4d54f50f615ead6cb..83f3118556df8f1a9fc03a9467f9354142b2bfe2 100644
--- 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'] = {
diff --git a/doc/administration/raketasks/github_import.md b/doc/administration/raketasks/github_import.md
index f29e2a6c7f662c7661ee58f841daaf92731fcec4..0cdfd1c28ff1811de4ec4a43db9fbe666a9de302 100644
--- 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
diff --git a/doc/administration/raketasks/project_import_export.md b/doc/administration/raketasks/project_import_export.md
index e0ca7bfdeaf405b133f19276a0c2885680b2e283..13f8dfdccc22e8223f440b01e8feaa57b95c5f51 100644
--- 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).
diff --git a/doc/api/sidekiq_metrics.md b/doc/api/sidekiq_metrics.md
index bcb59a6dad395a0d6d890c843c599892de4e37cc..2be2e71e551ff0cf274b3a53dbf26e98f074780f 100644
--- 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.
diff --git a/doc/install/requirements.md b/doc/install/requirements.md
index c136fb21a90ba4add9c520c0771bf89886e424c0..70b6de9b427741887630aa007d15d02625567ec5 100644
--- 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).
diff --git a/doc/update/zero_downtime.md b/doc/update/zero_downtime.md
index 7a74435267f194ba3a7ca533618b5e1731c031c1..6f00aa3b72bc94531069b9dfba317d1956948367 100644
--- a/doc/update/zero_downtime.md
+++ b/doc/update/zero_downtime.md
@@ -1,17 +1,17 @@
---
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