Docs: Changed since to and later

Closes: https://gitlab.com/gitlab-org/gitlab/-/issues/222328

doc/administration/database_load_balancing.md

@@ -128,7 +128,7 @@ production:
       disconnect_timeout: 120
 ```
 
-Here the `discover:` section specifies the configuration details to use for
+Here, the `discover:` section specifies the configuration details to use for
 service discovery.
 
 ### Configuration
@@ -139,7 +139,7 @@ The following options can be set:
 |----------------------|---------------------------------------------------------------------------------------------------|-----------|
 | `nameserver`         | The nameserver to use for looking up the DNS record.                                              | localhost |
 | `record`             | The record to look up. This option is required for service discovery to work.                     |           |
-| `record_type`        | Optional record type to look up, this can be either A or SRV (since GitLab 12.3)                  | A         |
+| `record_type`        | Optional record type to look up, this can be either A or SRV (GitLab 12.3 and later)              | A         |
 | `port`               | The port of the nameserver.                                                                       | 8600      |
 | `interval`           | The minimum time in seconds between checking the DNS record.                                      | 60        |
 | `disconnect_timeout` | The time in seconds after which an old connection is closed, after the list of hosts was updated. | 120       |

doc/administration/geo/index.md

@@ -67,7 +67,7 @@ Keep in mind that:
 - **Secondary** nodes talk to the **primary** node to:
   - Get user data for logins (API).
   - Replicate repositories, LFS Objects, and Attachments (HTTPS + JWT).
-- Since GitLab Premium 10.0, the **primary** node no longer talks to **secondary** nodes to notify for changes (API).
+- In GitLab Premium 10.0 and later, the **primary** node no longer talks to **secondary** nodes to notify for changes (API).
 - Pushing directly to a **secondary** node (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/releases/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
 - There are [limitations](#limitations) when using Geo.
 
@@ -282,7 +282,7 @@ For answers to common questions, see the [Geo FAQ](replication/faq.md).
 
 ## Log files
 
-Since GitLab 9.5, Geo stores structured log messages in a `geo.log` file. For Omnibus installations, this file is at `/var/log/gitlab/gitlab-rails/geo.log`.
+In GitLab 9.5 and later, Geo stores structured log messages in a `geo.log` file. For Omnibus installations, this file is at `/var/log/gitlab/gitlab-rails/geo.log`.
 
 This file contains information about when Geo attempts to sync repositories and files. Each line in the file contains a separate JSON entry that can be ingested into. For example, Elasticsearch or Splunk.
 

doc/administration/geo/replication/version_specific_updates.md

@@ -397,7 +397,7 @@ existing repositories was added in GitLab 10.1.
 
 ## Updating to GitLab 10.0
 
-Since GitLab 10.0, we require all **Geo** systems to [use SSH key lookups via
+In GitLab 10.0 and later, we require all **Geo** systems to [use SSH key lookups via
 the database](../../operations/fast_ssh_key_lookup.md) to avoid having to maintain consistency of the
 `authorized_keys` file for SSH access. Failing to do this will prevent users
 from being able to clone via SSH.
@@ -611,9 +611,9 @@ is prepended with the relevant node for better clarity:
 
 ### Update tracking database on **secondary** node
 
-After updating a **secondary** node, you might need to run migrations on
-the tracking database. The tracking database was added in GitLab 9.1,
-and it is required since 10.0.
+After updating a **secondary** node, you might need to run migrations on the
+tracking database. The tracking database was added in GitLab 9.1, and is
+required in GitLab 10.0 and later.
 
 1. Run database migrations on tracking database:
 

doc/administration/gitaly/index.md

@@ -93,7 +93,7 @@ When running Gitaly on its own server, note the following regarding GitLab versi
   NFS. To use Elasticsearch in these versions, the
   [repository indexer](../../integration/elasticsearch.md#elasticsearch-repository-indexer)
   must be enabled in your GitLab configuration.
-- [Since GitLab 12.3](https://gitlab.com/gitlab-org/gitlab/-/issues/6481), the new indexer is
+- [In GitLab 12.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/6481), the new indexer is
   the default and no configuration is required.
 
 ### Network architecture

doc/administration/operations/sidekiq_memory_killer.md

@@ -8,7 +8,7 @@ MemoryKiller applies the same approach to the Sidekiq processes used by GitLab
 to process background jobs.
 
 Unlike puma-worker-killer, which is enabled by default for all GitLab
-installations since GitLab 13.0, the Sidekiq MemoryKiller is enabled by default
+installations of GitLab 13.0 and later, the Sidekiq MemoryKiller is enabled by default
 _only_ for Omnibus packages. The reason for this is that the MemoryKiller
 relies on runit to restart Sidekiq after a memory-induced shutdown and GitLab
 installations from source do not all use runit or an equivalent.

doc/administration/raketasks/uploads/sanitize.md

 # Uploads sanitize Rake tasks **(CORE ONLY)**
 
-Since GitLab 11.9, EXIF data is automatically stripped from JPG or TIFF image uploads.
+In GitLab 11.9 and later, EXIF data is automatically stripped from JPG or TIFF image uploads.
 
 EXIF data may contain sensitive information (for example, GPS location), so you
 can remove EXIF data from existing images that were uploaded to an earlier version of GitLab.

doc/administration/troubleshooting/log_parsing.md

@@ -3,7 +3,7 @@
 We recommend using log aggregation and search tools like Kibana and Splunk whenever possible,
 but if they are not available you can still quickly parse
 [GitLab logs](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26311) in JSON format
-(the default since GitLab 12.0) using [`jq`](https://stedolan.github.io/jq/).
+(the default in GitLab 12.0 and later) using [`jq`](https://stedolan.github.io/jq/).
 
 ## What is JQ?
 

doc/administration/troubleshooting/tracing_correlation_id.md

@@ -4,7 +4,7 @@ type: reference
 
 # Finding relevant log entries with a correlation ID
 
-Since GitLab 11.6, a unique request tracking ID, known as the "correlation ID" has been
+In GitLab 11.6 and later, a unique request tracking ID, known as the "correlation ID" has been
 logged by the GitLab instance for most requests. Each individual request to GitLab gets
 its own correlation ID, which then gets logged in each GitLab component's logs for that
 request. This makes it easier to trace behavior in a

doc/api/commits.md

@@ -614,7 +614,7 @@ Example response:
 
 ## Commit status
 
-Since GitLab 8.1, this is the new commit status API.
+In GitLab 8.1 and later, this is the new commit status API.
 
 ### List the statuses of a commit
 

doc/api/container_registry.md

@@ -272,7 +272,7 @@ action doesn't delete blobs. To delete them and recycle disk space,
 [run the garbage collection](https://docs.gitlab.com/omnibus/maintenance/README.html#removing-unused-layers-not-referenced-by-manifests).
 
 NOTE: **Note:**
-Since GitLab 12.4, individual tags are deleted.
+In GitLab 12.4 and later, individual tags are deleted.
 For more details, see the [discussion](https://gitlab.com/gitlab-org/gitlab/-/issues/15737).
 
 Examples:

doc/api/instance_level_ci_variables.md

@@ -70,7 +70,7 @@ curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/a
 
 Create a new instance-level variable.
 
-[Since GitLab 13.1](https://gitlab.com/gitlab-org/gitlab/-/issues/216097), the maximum number of allowed instance-level variables can be changed.
+[In GitLab 13.1 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/216097), the maximum number of allowed instance-level variables can be changed.
 
 ```plaintext
 POST /admin/ci/variables
@@ -79,7 +79,7 @@ POST /admin/ci/variables
 | Attribute       | Type    | required | Description           |
 |-----------------|---------|----------|-----------------------|
 | `key`           | string  | yes      | The `key` of a variable. Max 255 characters, only `A-Z`, `a-z`, `0-9`, and `_` are allowed. |
-| `value`         | string  | yes      | The `value` of a variable. 10,000 characters allowed. [Since GitLab 13.3](https://gitlab.com/gitlab-org/gitlab/-/issues/220028) |
+| `value`         | string  | yes      | The `value` of a variable. 10,000 characters allowed ([GitLab 13.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/220028)). |
 | `variable_type` | string  | no       | The type of a variable. Available types are: `env_var` (default) and `file`. |
 | `protected`     | boolean | no       | Whether the variable is protected. |
 | `masked`        | boolean | no       | Whether the variable is masked. |
@@ -109,7 +109,7 @@ PUT /admin/ci/variables/:key
 | Attribute       | Type    | required | Description             |
 |-----------------|---------|----------|-------------------------|
 | `key`           | string  | yes      | The `key` of a variable.   |
-| `value`         | string  | yes      | The `value` of a variable. [Since GitLab 13.3](https://gitlab.com/gitlab-org/gitlab/-/issues/220028), around 10,000 characters allowed. Previously 700 characters. |
+| `value`         | string  | yes      | The `value` of a variable. 10,000 characters allowed ([GitLab 13.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/220028)). |
 | `variable_type` | string  | no       | The type of a variable. Available types are: `env_var` (default) and `file`. |
 | `protected`     | boolean | no       | Whether the variable is protected. |
 | `masked`        | boolean | no       | Whether the variable is masked. |

doc/api/v3_to_v4.md

 # API V3 to API V4
 
-Since GitLab 9.0, API V4 is the preferred version to be used.
+In GitLab 9.0 and later, API V4 is the preferred version to be used.
 
 API V3 was unsupported from GitLab 9.5, released on August
 22, 2017. API v3 was removed in [GitLab 11.0](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/36819).

doc/ci/environments/index.md

@@ -892,7 +892,7 @@ you can monitor the behavior of your app running in each environment. For the mo
 dashboard to appear, you need to Configure Prometheus to collect at least one
 [supported metric](../../user/project/integrations/prometheus_library/index.md).
 
-Since GitLab 9.2, all deployments to an environment are shown directly on the monitoring dashboard.
+In GitLab 9.2 and later, all deployments to an environment are shown directly on the monitoring dashboard.
 
 Once configured, GitLab will attempt to retrieve [supported performance metrics](../../user/project/integrations/prometheus_library/index.md)
 for any environment that has had a successful deployment. If monitoring data was
@@ -956,7 +956,7 @@ session and even a multiplexer like `screen` or `tmux`.
 
 ### Check out deployments locally
 
-Since GitLab 8.13, a reference in the Git repository is saved for each deployment, so
+In GitLab 8.13 and later, a reference in the Git repository is saved for each deployment, so
 knowing the state of your current environments is only a `git fetch` away.
 
 In your Git configuration, append the `[remote "<your-remote>"]` block with an extra

doc/ci/pipelines/index.md

@@ -101,8 +101,8 @@ you can filter the pipeline list by:
 
 - Trigger author
 - Branch name
-- Status ([since GitLab 13.1](https://gitlab.com/gitlab-org/gitlab/-/issues/217617))
-- Tag ([since GitLab 13.1](https://gitlab.com/gitlab-org/gitlab/-/issues/217617))
+- Status ([GitLab 13.1 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/217617))
+- Tag ([GitLab 13.1 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/217617))
 
 ### Run a pipeline manually
 
@@ -114,7 +114,7 @@ operation of the pipeline.
 To execute a pipeline manually:
 
 1. Navigate to your project's **CI/CD > Pipelines**.
-1. Click on the **Run Pipeline** button.
+1. Select the **Run Pipeline** button.
 1. On the **Run Pipeline** page:
     1. Select the branch to run the pipeline for in the **Create for** field.
     1. Enter any [environment variables](../variables/README.md) required for the pipeline run.

doc/ci/variables/README.md

@@ -448,7 +448,7 @@ To add an instance-level variable:
 1. Click the **Add variable** button, and fill in the details:
 
    - **Key**: Must be one line, using only letters, numbers, or `_` (underscore), with no spaces.
-   - **Value**: [Since GitLab 13.3](https://gitlab.com/gitlab-org/gitlab/-/issues/220028), 10,000 characters allowed. This is also bounded by the limits of the selected runner operating system. In GitLab 13.0 to 13.2, 700 characters allowed.
+   - **Value**: [In GitLab 13.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/220028), 10,000 characters allowed. This is also bounded by the limits of the selected runner operating system. In GitLab 13.0 to 13.2, 700 characters allowed.
    - **Type**: `File` or `Variable`.
    - **Protect variable** (Optional): If selected, the variable is only available in pipelines that run on protected branches or tags.
    - **Mask variable** (Optional): If selected, the variable's **Value** is not shown in job logs. The variable is not saved if the value does not meet the [masking requirements](#masked-variable-requirements).

doc/ci/yaml/README.md

@@ -388,7 +388,7 @@ include:
 ### `include`
 
 > - Introduced in [GitLab Premium](https://about.gitlab.com/pricing/) 10.5.
-> - Available for Starter, Premium and Ultimate since 10.6.
+> - Available for Starter, Premium, and Ultimate in GitLab 10.6 and later.
 > - [Moved](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/42861) to GitLab Core in 11.4.
 
 Using the `include` keyword allows the inclusion of external YAML files. This helps
@@ -541,7 +541,7 @@ Nested includes allow you to compose a set of includes.
 
 A total of 100 includes is allowed, but duplicate includes are considered a configuration error.
 
-Since [GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/-/issues/28212), the time limit
+In [GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/-/issues/28212) and later, the time limit
 for resolving all files is 30 seconds.
 
 #### Additional `includes` examples
@@ -1487,9 +1487,8 @@ job:
         - spec/**.rb
 ```
 
-NOTE: **Note:**
-For performance reasons, using `exists` with patterns is limited to 10000
-checks. After the 10000th check, rules with patterned globs always match.
+For performance reasons, using `exists` with patterns is limited to 10,000
+checks. After the 10,000th check, rules with patterned globs always match.
 
 #### `rules:allow_failure`
 
@@ -2093,7 +2092,7 @@ To disable directed acyclic graphs (DAG), set the limit to `0`.
 
 When using `needs`, artifact downloads are controlled with `artifacts: true` (default) or `artifacts: false`.
 
-Since GitLab 12.6, you can't combine the [`dependencies`](#dependencies) keyword
+In GitLab 12.6 and later, you can't combine the [`dependencies`](#dependencies) keyword
 with `needs` to control artifact downloads in jobs. `dependencies` is still valid
 in jobs that do not use `needs`.
 
@@ -3627,7 +3626,7 @@ You can use this keyword to create two different types of downstream pipelines:
 - [Multi-project pipelines](../multi_project_pipelines.md#creating-multi-project-pipelines-from-gitlab-ciyml)
 - [Child pipelines](../parent_child_pipelines.md)
 
-[In GitLab 13.2 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/197140/), you can
+[In GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/issues/197140/) and later, you can
 view which job triggered a downstream pipeline. In the [pipeline graph](../pipelines/index.md#visualize-pipelines),
 hover over the downstream pipeline job.
 
@@ -4378,7 +4377,7 @@ the following stages:
 | Variable                          | Description                                            |
 |-----------------------------------|--------------------------------------------------------|
 | **ARTIFACT_DOWNLOAD_ATTEMPTS**    | Number of attempts to download artifacts running a job |
-| **EXECUTOR_JOB_SECTION_ATTEMPTS** | [Since GitLab 12.10](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4450), the number of attempts to run a section in a job after a [`No Such Container`](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4450) error ([Docker executor](https://docs.gitlab.com/runner/executors/docker.html) only). |
+| **EXECUTOR_JOB_SECTION_ATTEMPTS** | [In GitLab 12.10](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4450) and later, the number of attempts to run a section in a job after a [`No Such Container`](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4450) error ([Docker executor](https://docs.gitlab.com/runner/executors/docker.html) only). |
 | **GET_SOURCES_ATTEMPTS**          | Number of attempts to fetch sources running a job      |
 | **RESTORE_CACHE_ATTEMPTS**        | Number of attempts to restore the cache running a job  |
 

doc/development/database/not_null_constraints.md

@@ -39,7 +39,7 @@ end
 
 ## Add a `NOT NULL` column to an existing table
 
-With PostgreSQL 11 being the minimum version since GitLab 13.0, adding columns with `NULL` and/or
+With PostgreSQL 11 being the minimum version in GitLab 13.0 and later, adding columns with `NULL` and/or
 default values has become much easier and the standard `add_column` helper should be used in all cases.
 
 For example, consider a migration that adds a new `NOT NULL` column `active` to table `db_guides`,

doc/development/geo.md

@@ -426,7 +426,7 @@ We switch and filter from each event by the `event_name` field.
 
 ### Geo Log Cursor (GitLab 10.0 and up)
 
-Since GitLab 10.0, [System Webhooks](#system-hooks-gitlab-87-to-95) are no longer
+In GitLab 10.0 and later, [System Webhooks](#system-hooks-gitlab-87-to-95) are no longer
 used and Geo Log Cursor is used instead. The Log Cursor traverses the
 `Geo::EventLog` rows to see if there are changes since the last time
 the log was checked and will handle repository updates, deletes,

doc/development/go_guide/index.md

@@ -138,7 +138,7 @@ security status and license compatibility.
 
 ### Modules
 
-Since Go 1.11, a standard dependency system is available behind the name [Go
+In Go 1.11 and later, a standard dependency system is available behind the name [Go
 Modules](https://github.com/golang/go/wiki/Modules). It provides a way to
 define and lock dependencies for reproducible builds. It should be used
 whenever possible.
@@ -472,7 +472,7 @@ In case we want to drop support for `go 1.11` in GitLab `12.10`, we need to veri
 
 We will not consider the active milestone, `12.10`, because a backport for `12.7` will be required in case of a critical security release.
 
-1. If both [Omnibus and CNG](#updating-go-version) were using Go `1.12` since GitLab `12.7`, then we safely drop support for `1.11`.
+1. If both [Omnibus and CNG](#updating-go-version) were using Go `1.12` in GitLab `12.7` and later, then we safely drop support for `1.11`.
 1. If Omnibus or CNG were using `1.11` in GitLab `12.7`, then we still need to keep support for Go `1.11` for easier backporting of security fixes.
 
 ## Secure Team standards and style guidelines

doc/development/gotchas.md

@@ -5,7 +5,7 @@ might encounter or should avoid during development of GitLab CE and EE.
 
 ## Do not read files from app/assets directory
 
-Since GitLab 10.8, Omnibus has [dropped the `app/assets` directory](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/2456),
+In GitLab 10.8 and later, Omnibus has [dropped the `app/assets` directory](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/2456),
 after asset compilation. The `ee/app/assets`, `vendor/assets` directories are dropped as well.
 
 This means that reading files from that directory will fail in Omnibus-installed GitLab instances:

doc/development/migration_style_guide.md

@@ -602,7 +602,7 @@ See the style guide on [`NOT NULL` constraints](database/not_null_constraints.md
 
 ## Adding Columns With Default Values
 
-With PostgreSQL 11 being the minimum version since GitLab 13.0, adding columns with default values has become much easier and
+With PostgreSQL 11 being the minimum version in GitLab 13.0 and later, adding columns with default values has become much easier and
 the standard `add_column` helper should be used in all cases.
 
 Before PostgreSQL 11, adding a column with a default was problematic as it would

doc/install/aws/index.md

@@ -466,7 +466,7 @@ Connect to your GitLab instance via **Bastion Host A** using [SSH Agent Forwardi
 
 #### Disable Let's Encrypt
 
-Since we're adding our SSL certificate at the load balancer, we do not need GitLab's built-in support for Let's Encrypt. Let's Encrypt [is enabled by default](https://docs.gitlab.com/omnibus/settings/ssl.html#lets-encrypt-integration) when using an `https` domain since GitLab 10.7, so we need to explicitly disable it:
+Since we're adding our SSL certificate at the load balancer, we do not need GitLab's built-in support for Let's Encrypt. Let's Encrypt [is enabled by default](https://docs.gitlab.com/omnibus/settings/ssl.html#lets-encrypt-integration) when using an `https` domain in GitLab 10.7 and later, so we need to explicitly disable it:
 
 1. Open `/etc/gitlab/gitlab.rb` and disable it:
 

doc/install/installation.md

@@ -260,7 +260,7 @@ sudo gem install bundler --no-document --version '< 2'
 
 ## 3. Go
 
-Since GitLab 8.0, GitLab has several daemons written in Go. To install
+In GitLab 8.0 and later, GitLab has several daemons written in Go. To install
 GitLab we need a Go compiler. The instructions below assume you use 64-bit
 Linux. You can find downloads for other platforms at the [Go download
 page](https://golang.org/dl).
@@ -278,7 +278,7 @@ rm go1.13.5.linux-amd64.tar.gz
 
 ## 4. Node
 
-Since GitLab 8.17, GitLab requires the use of Node to compile JavaScript
+In GitLab 8.17 and later, GitLab requires the use of Node to compile JavaScript
 assets, and Yarn to manage JavaScript dependencies. The current minimum
 requirements for these are:
 
@@ -313,7 +313,7 @@ sudo adduser --disabled-login --gecos 'GitLab' git
 ## 6. Database
 
 NOTE: **Note:**
-Starting from GitLab 12.1, only PostgreSQL is supported. Since GitLab 13.0, we [require PostgreSQL 11+](requirements.md#postgresql-requirements).
+In GitLab 12.1 and later, only PostgreSQL is supported. In GitLab 13.0 and later, we [require PostgreSQL 11+](requirements.md#postgresql-requirements).
 
 1. Install the database packages:
 

doc/raketasks/import.md

@@ -127,7 +127,7 @@ Bare repositories are **not** importable by GitLab 10.4 to GitLab 11.6, if all t
 - It was not renamed, transferred, or migrated to [hashed storage](../administration/repository_storage_types.md#hashed-storage) in GitLab 10.4 to GitLab 11.6.
 - Its ancestor namespaces were not renamed or transferred in GitLab 10.4 to GitLab 11.6.
 
-[Since GitLab 11.6](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/41776), all
+[In GitLab 11.6](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/41776) and later, all
 bare repositories are importable.
 
 To manually migrate repositories yourself (for GitLab 10.4 to GitLab 11.6), you can use the

doc/topics/autodevops/stages.md

@@ -247,7 +247,7 @@ Helm, which you can [customize](customize.md#custom-helm-chart). The application
 into the [Kubernetes namespace](../../user/project/clusters/index.md#deployment-variables)
 for the environment.
 
-Since GitLab 11.4, [local Tiller](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22036) is
+In GitLab 11.4 and later, [local Tiller](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22036) is
 used. Previous versions of GitLab had a Tiller installed in the project
 namespace.
 
@@ -365,7 +365,7 @@ chart to deploy the application into the
 [Kubernetes namespace](../../user/project/clusters/index.md#deployment-variables)
 for the environment.
 
-Since GitLab 11.4, a
+In GitLab 11.4 and later, a
 [local Tiller](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22036) is
 used. Previous versions of GitLab had a Tiller installed in the project
 namespace.

doc/user/clusters/applications.md

@@ -63,7 +63,7 @@ supported by GitLab before installing any of the applications.
 
 > - Introduced in GitLab 10.2 for project-level clusters.
 > - Introduced in GitLab 11.6 for group-level clusters.
-> - [Uses a local Tiller](https://gitlab.com/gitlab-org/gitlab/-/issues/209736) since GitLab 13.2.
+> - [Uses a local Tiller](https://gitlab.com/gitlab-org/gitlab/-/issues/209736) in GitLab 13.2 and later.
 
 [Helm](https://helm.sh/docs/) is a package manager for Kubernetes and is
 used to install the GitLab-managed apps. GitLab runs each `helm` command

doc/user/group/index.md

@@ -371,7 +371,7 @@ To create group links via filter:
 
 ### Overriding user permissions **(STARTER ONLY)**
 
-Since GitLab [v8.15](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/822) LDAP user permissions can now be manually overridden by an admin user. To override a user's permissions:
+In GitLab [8.15](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/822) and later, LDAP user permissions can now be manually overridden by an admin user. To override a user's permissions:
 
 1. Go to your group's **Members** page.
 1. Select the pencil icon in the row for the user you are editing.

doc/user/permissions.md

@@ -438,7 +438,7 @@ instance and project. In addition, all admins can use the admin interface under
 
 1. Only if the job was:
    - Triggered by the user
-   - [Since GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/35069), not run for a protected branch
+   - [In GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/35069) and later, not run for a protected branch
 
 ### Job permissions
 
@@ -485,7 +485,7 @@ for details about the pipelines security model.
 
 ## LDAP users permissions
 
-Since GitLab 8.15, LDAP user permissions can now be manually overridden by an admin user.
+In GitLab 8.15 and later, LDAP user permissions can now be manually overridden by an admin user.
 Read through the documentation on [LDAP users permissions](group/index.md#manage-group-memberships-via-ldap) to learn more.
 
 ## Project aliases

doc/user/project/issues/issue_data_and_actions.md

@@ -191,7 +191,7 @@ The plain text title and description of the issue fill the top center of the iss
 The description fully supports [GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown-gfm),
 allowing many formatting options.
 
-> [Since GitLab 12.6](https://gitlab.com/gitlab-org/gitlab/-/issues/10103), changes to an issue's description are listed in the [issue history](#issue-history).**(STARTER)**
+> [In GitLab 12.6](https://gitlab.com/gitlab-org/gitlab/-/issues/10103) and later, changes to an issue's description are listed in the [issue history](#issue-history).**(STARTER)**
 
 ### Mentions
 

doc/user/project/merge_requests/revert_changes.md

@@ -14,7 +14,7 @@ by clicking the **Revert** button in merge requests and commit details.
 
 NOTE: **Note:**
 The **Revert** button will only be available for merge requests
-created since GitLab 8.5. However, you can still revert a merge request
+created in GitLab 8.5 and later. However, you can still revert a merge request
 by reverting the merge commit from the list of Commits page.
 
 NOTE: **Note:**

doc/user/project/protected_branches.md

@@ -48,7 +48,7 @@ that the `master` branch is protected by default.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/5081) in GitLab 8.11.
 
-Since GitLab 8.11, we added another layer of branch protection which provides
+In GitLab 8.11 and later, we added another layer of branch protection which provides
 more granular management of protected branches. The "Developers can push"
 option was replaced by an "Allowed to push" setting which can be set to
 allow/prohibit Maintainers and/or Developers to push to a protected branch.

doc/user/todos.md

@@ -51,7 +51,7 @@ A to do item appears on your To-Do List when:
   - You're the author.
   - You're the user that set the merge request to automatically merge after a
     pipeline succeeds.
-- [Since GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/issues/12136), a
+- [In GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/issues/12136) and later, a
   merge request is removed from a
   [merge train](../ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md),
   and you're the user that added it. **(PREMIUM)**