docs: remove version notes - rely on docs versioning (argoproj#10338)

Signed-off-by: CI <[email protected]>

Signed-off-by: CI <[email protected]>

docs/developer-guide/api-docs.md

@@ -20,8 +20,6 @@ $ curl $ARGOCD_SERVER/api/v1/applications --cookie "argocd.token=$ARGOCD_TOKEN"
 {"metadata":{"selfLink":"/apis/argoproj.io/v1alpha1/namespaces/argocd/applications","resourceVersion":"37755"},"items":...}
 ```
 
-> v1.3
-
 Then pass using the HTTP `Authorization` header, prefixing with `Bearer `:
 
 ```bash

docs/operator-manual/applicationset/GoTemplate.md

@@ -1,7 +1,5 @@
 # Go Template
 
-> v2.5
-
 ## Introduction
 
 ApplicationSet is able to use [Go Text Template](https://pkg.go.dev/text/template). To activate this feature, add 

docs/operator-manual/declarative-setup.md

@@ -330,8 +330,6 @@ The following keys are valid to refer to credential secrets:
 
 ### Repositories using self-signed TLS certificates (or are signed by custom CA)
 
-> v1.2 or later
-
 You can manage the TLS certificates used to verify the authenticity of your repository servers in a ConfigMap object named `argocd-tls-certs-cm`. The data section should contain a map, with the repository server's hostname part (not the complete URL) as key, and the certificate(s) in PEM format as data. So, if you connect to a repository with the URL `https://server.example.com/repos/my-repo`, you should use `server.example.com` as key. The certificate data should be either the server's certificate (in case of self-signed certificate) or the certificate of the CA that was used to sign the server's certificate. You can configure multiple certificates for each server, e.g. if you are having a certificate roll-over planned.
 
 If there are no dedicated certificates configured for a repository server, the system's default trust store is used for validating the server's repository. This should be good enough for most (if not all) public Git repository services such as GitLab, GitHub and Bitbucket as well as most privately hosted sites which use certificates from well-known CAs, including Let's Encrypt certificates.

docs/operator-manual/tls.md

@@ -113,7 +113,7 @@ for the `argocd-repo-server`, containing at least the entries for
 `DNS:argocd-repo-server` and `DNS:argocd-repo-server.argo-cd.svc` depending
 on how your workloads connect to the repository server.
 
-## Configuring inbound TLS for argocd-dex-server > v2.5
+## Configuring inbound TLS for argocd-dex-server
 
 ### Inbound TLS options for argocd-dex-server
 
@@ -185,7 +185,7 @@ certificate stored in the `argocd-repo-server-tls` secret.
     mind that when you have to replace the certificate, all workloads have
     to be restarted in order to properly work again.
 
-### Configuring TLS to argocd-dex-server > v2.5
+### Configuring TLS to argocd-dex-server
 
 `argocd-server` communicates with the `argocd-dex-server` using an HTTPS API
 over TLS. By default, `argocd-dex-server` generates a non-persistent, self

docs/user-guide/config-management-plugins.md

@@ -163,8 +163,6 @@ CMP commands have access to
 2. [Standard build environment](build-environment.md)
 3. Variables in the application spec (References to system and build variables will get interpolated in the variables' values):
 
-> v1.2
-
 ```yaml
 spec:
   source:
@@ -179,8 +177,6 @@ spec:
 !!! note
     The `discover.command` command only has access to the above environment starting with v2.4.
 
-> v2.4
-
 Before reaching the `init.command`, `generate.command`, and `discover.command` commands, Argo CD prefixes all 
 user-supplied environment variables (#3 above) with `ARGOCD_ENV_`. This prevents users from directly setting 
 potentially-sensitive environment variables.

docs/user-guide/helm.md

@@ -75,8 +75,6 @@ source:
 
 ## Helm Hooks
 
-> v1.3 or later
-
 Helm hooks are similar to [Argo CD hooks](resource_hooks.md). In Helm, a hook
 is any normal Kubernetes resource annotated with the `helm.sh/hook` annotation.
 
@@ -142,8 +140,6 @@ argocd app set redis -p password=abc123
 
 ## Build Environment
 
-> v1.4
-
 Helm apps have access to the [standard build environment](build-environment.md) via substitution as parameters.
 
 E.g. via the CLI:
@@ -177,8 +173,6 @@ It's also possible to use build environment variables for the Helm values file p
 
 ## Helm plugins
 
-> v1.5
-
 Argo CD is un-opinionated on what cloud provider you use and what kind of Helm plugins you are using, that's why there are no plugins delivered with the ArgoCD image.
 
 But sometimes you want to use a custom plugin. Perhaps you would like to use Google Cloud Storage or Amazon S3 storage to save the Helm charts, for example: https://github.com/hayorov/helm-gcs where you can use `gs://` protocol for Helm chart repository access.

docs/user-guide/jsonnet.md

@@ -4,8 +4,6 @@ Any file matching `*.jsonnet` in a directory app is treated as a Jsonnet file. A
 
 ## Build Environment
 
-> v1.4
-
 Jsonnet apps have access to the [standard build environment](build-environment.md) via substitution into *TLAs* and *external variables*.
 It is also possible to add a shared library (e.g. `vendor` folder) relative to the repository root.
 

docs/user-guide/private-repositories.md

@@ -22,8 +22,6 @@ argocd repo add https://github.com/argoproj/argocd-example-apps --username <user
 
 or UI:
 
-> v1.2 or later
-
 1. Navigate to `Settings/Repositories`
 
     ![connect repo overview](../assets/repo-add-overview.png)
@@ -59,8 +57,6 @@ Then, connect the repository using any non-empty string as username and the acce
 
 ### TLS Client Certificates for HTTPS repositories
 
-> v1.2 and later
-
 If your repository server requires you to use TLS client certificates for authentication, you can configure ArgoCD repositories to make use of them. For this purpose, `--tls-client-cert-path` and `--tls-client-cert-key-path` switches to the `argocd repo add` command can be used to specify the files on your local system containing client certificate and the corresponding key, respectively:
 
 ```
@@ -81,8 +77,6 @@ Your TLS client certificate and corresponding key can also be configured using t
 
 Private repositories that require an SSH private key have a URL that typically start with `git@` or `ssh://` rather than `https://`.  
 
-> v1.2 or later
-
 You can configure your Git repository using SSH either using the CLI or the UI.
 
 !!! note
@@ -130,12 +124,6 @@ Private repositories that are hosted on GitHub.com or GitHub Enterprise can be a
 !!!note
     Ensure your application has at least `Read-only` permissions to the `Contents` of the repository. This is the minimum requirement.
 
-> previous to v1.9
-
-GitHub App credentials are not supported.
-
-> v1.9 or later
-
 You can configure access to your Git repository hosted by GitHub.com or GitHub Enterprise using the GitHub App method by either using the CLI or the UI.
 
 Using the CLI:
@@ -161,12 +149,6 @@ Using the UI:
 
 ## Credential templates
 
-> previous to v1.4
-
-Credential templates are available only via declarative setup, see [Repository credentials](../../operator-manual/declarative-setup#repository-credentials) in Operator Manual.
-
-> v1.4 and later
-
 You can also set up credentials to serve as templates for connecting repositories, without having to repeat credential configuration. For example, if you setup credential templates for the URL prefix `https://github.com/argoproj`, these credentials will be used for all repositories with this URL as prefix (e.g. `https://github.com/argoproj/argocd-example-apps`) that do not have their own credentials configured.
 
 To set up a credential template using the Web UI, simply fill in all relevant credential information in the __Connect repo using SSH__ or __Connect repo using HTTPS__ dialogues (as described above), but select __Save as credential template__ instead of __Connect__ to save the credential template. Be sure to only enter the prefix URL (i.e. `https://github.com/argoproj`) instead of the complete repository URL (i.e. `https://github.com/argoproj/argocd-example-apps`) in the field __Repository URL__
@@ -208,8 +190,6 @@ FATA[0000] rpc error: code = Unknown desc = authentication required
 
 ## Self-signed & Untrusted TLS Certificates
 
-> v1.2 or later
-
 If you are connecting a repository on a HTTPS server using a self-signed certificate, or a certificate signed by a custom Certificate Authority (CA) which are not known to ArgoCD, the repository will not be added due to security reasons. This is indicated by an error message such as `x509: certificate signed by unknown authority`.
 
 1. You can let ArgoCD connect the repository in an insecure way, without verifying the server's certificate at all. This can be accomplished by using the `--insecure-skip-server-verification` flag when adding the repository with the `argocd` CLI utility. However, this should be done only for non-production setups, as it imposes a serious security issue through possible man-in-the-middle attacks.
@@ -298,8 +278,6 @@ As a work-around, you can customize your Argo CD image. See [#1344](https://gith
 
 If you are using a privately hosted Git service over SSH, then you have the following  options:
 
-> v1.2 or later
-
 1. You can let ArgoCD connect the repository in an insecure way, without verifying the server's SSH host key at all. This can be accomplished by using the `--insecure-skip-server-verification` flag when adding the repository with the `argocd` CLI utility. However, this should be done only for non-production setups, as it imposes a serious security issue through possible man-in-the-middle attacks.
 
 2. You can make the server's SSH public key known to ArgoCD by using the `cert add-ssh` command of the `argocd` CLI utility. This is the recommended method and suitable for production use. In order to do so, you will need the server's SSH public host key, in the `known_hosts` format understood by `ssh`. You can get the server's public SSH host key e.g. by using the `ssh-keyscan` utility.
@@ -398,8 +376,6 @@ argocd repo add [email protected]:argoproj/argocd-example-apps.git --ssh-private-ke
 
 ## Git Submodules
 
-> v1.4 or later
-
 Submodules are supported and will be picked up automatically. If the submodule repository requires authentication then the credentials will need to match the credentials of the parent repository. Set ARGOCD_GIT_MODULES_ENABLED=false to disable submodule support
 
 ## Declarative Configuration

docs/user-guide/status-badge.md

@@ -1,7 +1,5 @@
 # Status Badge
 
-> v1.2
-
 Argo CD can display a badge with health and sync status for any application. The feature is disabled by default because badge image is available to any user without authentication.
 The feature can be enabled using `statusbadge.enabled` key of `argocd-cm` ConfigMap (see [argocd-cm.yaml](../operator-manual/argocd-cm.yaml)).