Merge branch 'docs-access-rem-vers' into 'master'

Remove outdated versions from Access docs

See merge request gitlab-org/gitlab!71871

doc/api/access_requests.md

@@ -2,13 +2,10 @@
 stage: Manage
 group: Access
 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, api
 ---
 
 # Group and project access requests API **(FREE)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/18583) in GitLab 8.11.
-
 ## Valid access levels
 
 The access levels are defined in the `Gitlab::Access` module, and the

doc/integration/kerberos.md

@@ -2,7 +2,6 @@
 stage: Manage
 group: Access
 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, how-to
 ---
 
 # Kerberos integration **(PREMIUM SELF)**
@@ -296,7 +295,7 @@ Kerberos ticket-based authentication.
 
 ## Upgrading from password-based to ticket-based Kerberos sign-ins
 
-Prior to GitLab 8.10 Enterprise Edition, users had to submit their
+In previous versions of GitLab users had to submit their
 Kerberos username and password to GitLab when signing in. We plan to
 remove support for password-based Kerberos sign-ins in a future
 release, so we recommend that you upgrade to ticket-based sign-ins.

doc/user/permissions.md

@@ -33,8 +33,6 @@ usernames. A GitLab administrator can configure the GitLab instance to
 
 ## Project members permissions
 
-> The Master role was renamed to Maintainer in GitLab 11.0.
-
 The Owner role is only available at the group or personal namespace level (and for instance administrators) and is inherited by its projects.
 While Maintainer is the highest project-level role, some actions can only be performed by a personal namespace or group owner, or an instance administrator, who receives all permissions.
 For more information, see [projects members documentation](project/members/index.md).
@@ -269,9 +267,6 @@ Find the visibility permissions for the Container Registry, as described in the
 
 ## Group members permissions
 
-NOTE:
-In GitLab 11.0, the Master role was renamed to Maintainer.
-
 Any user can remove themselves from a group, unless they are the last Owner of
 the group.
 
@@ -442,8 +437,6 @@ free guest user.
 
 ## Auditor users **(PREMIUM SELF)**
 
->[Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/998) in [GitLab Premium](https://about.gitlab.com/pricing/) 8.17.
-
 Auditor users are given read-only access to all projects, groups, and other
 resources on the GitLab instance.
 
@@ -454,7 +447,7 @@ with the permissions described on the documentation on [auditor users permission
 
 ## Users with minimal access **(PREMIUM)**
 
->[Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40942) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.4.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40942) in [GitLab Premium](https://about.gitlab.com/pricing/) 13.4.
 
 Owners can add members with a "minimal access" role to a parent group. Such users don't
 automatically have access to projects and subgroups underneath. To support such access, owners must explicitly add these "minimal access" users to the specific subgroups/projects.
@@ -480,9 +473,6 @@ which visibility level you select on project settings.
 
 ## GitLab CI/CD permissions
 
-NOTE:
-In GitLab 11.0, the Master role was renamed to Maintainer.
-
 GitLab CI/CD permissions rely on the role the user has in GitLab. There are four
 roles:
 
@@ -513,9 +503,6 @@ instance and project.
 
 ### Job permissions
 
-NOTE:
-In GitLab 11.0, the Master role was renamed to Maintainer.
-
 This table shows granted privileges for jobs triggered by specific types of
 users:
 
@@ -555,7 +542,7 @@ for more information.
 
 ## LDAP users permissions
 
-In GitLab 8.15 and later, LDAP user permissions can now be manually overridden by an administrator.
+LDAP user permissions can be manually overridden by an administrator.
 Read through the documentation on [LDAP users permissions](group/index.md#manage-group-memberships-via-ldap) to learn more.
 
 ## Project aliases

doc/user/profile/account/two_factor_authentication.md

 ---
-type: howto
 stage: Manage
 group: Access
 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
@@ -235,8 +234,6 @@ Feature.disable(:forti_token_cloud, User.find(<user ID>))
 
 ### U2F device
 
-> Introduced in [GitLab 8.9](https://about.gitlab.com/blog/2016/06/22/gitlab-adds-support-for-u2f/).
-
 GitLab officially only supports [YubiKey](https://www.yubico.com/products/)
 U2F devices, but users have successfully used [SoloKeys](https://solokeys.com/)
 or [Google Titan Security Key](https://cloud.google.com/titan-security-key).