docs: consistently use "> v{version} and after"

.spelling

@@ -211,6 +211,7 @@ v2
 v2.0
 v2.1
 v2.10
+v2.10.2
 v2.11
 v2.12
 v2.35.0

docs/argo-server-sso.md

@@ -197,7 +197,7 @@ workflows.argoproj.io/rbac-rule: "'argo_admins' in groups"
 
 ## Filtering groups
 
-> v3.5 and above
+> v3.5 and after
 
 You can configure `filterGroupsRegex` to filter the groups returned by the OIDC provider. Some use-cases for this include:
 

docs/artifact-visualization.md

@@ -1,6 +1,6 @@
 # Artifact Visualization
 
-> since v3.4
+> v3.4 and after
 
 Artifacts can be viewed in the UI.
 

docs/cluster-workflow-templates.md

@@ -56,10 +56,10 @@ spec:
               value: "hello world"
 ```
 
-> 2.9 and after
-
 ### Create `Workflow` from `ClusterWorkflowTemplate` Spec
 
+> v2.9 and after
+
 You can create `Workflow` from `ClusterWorkflowTemplate` spec using `workflowTemplateRef` with `clusterScope: true`. If you pass the arguments to created `Workflow`, it will be merged with cluster workflow template arguments
 
 Here is an example for `ClusterWorkflowTemplate` with `entrypoint` and `arguments`
@@ -129,15 +129,15 @@ You can create some example templates as follows:
 argo cluster-template create https://raw.githubusercontent.com/argoproj/argo-workflows/main/examples/cluster-workflow-template/clustertemplates.yaml
 ```
 
-The submit a workflow using one of those templates:
+Then submit a `Workflow` using one of those templates:
 
 ```bash
 argo submit https://raw.githubusercontent.com/argoproj/argo-workflows/main/examples/cluster-workflow-template/cluster-wftmpl-dag.yaml
 ```
 
-> 2.7 and after
->
-The submit a `ClusterWorkflowTemplate` as a `Workflow`:
+> v2.7 and after
+
+Then submit a `ClusterWorkflowTemplate` as a `Workflow`:
 
 ```bash
 argo submit --from clusterworkflowtemplate/cluster-workflow-template-submittable

docs/executor_plugins.md

@@ -1,6 +1,6 @@
 # Executor Plugins
 
-> Since v3.3
+> v3.3 and after
 
 ## Configuration
 

docs/high-availability.md

@@ -4,7 +4,7 @@
 
 Before v3.0, only one controller could run at once. (If it crashed, Kubernetes would start another pod.)
 
-> v3.0
+> v3.0 and after
 
 For many users, a short loss of workflow service may be acceptable - the new controller will just continue running
 workflows if it restarts.  However, with high service guarantees, new pods may take too long to start running workflows.
@@ -18,9 +18,9 @@ Budget to prevent this and Pod Priority to recover faster from an involuntary po
 
 ## Argo Server
 
-> v2.6
+> v2.6 and after
 
 Run a minimum of two replicas, typically three, should be run, otherwise it may be possible that API and webhook requests are dropped.
 
 !!! Tip
-    Consider using [multi AZ-deployment using pod anti-affinity](https://www.verygoodsecurity.com/blog/posts/kubernetes-multi-az-deployments-using-pod-anti-affinity).
+    Consider [spreading Pods across multiple availability zones](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/).

docs/resource-template.md

@@ -1,5 +1,5 @@
 # Resource Template
 
-> v2.0
+> v2.0 and after
 
 See [Kubernetes Resources](walk-through/kubernetes-resources.md).

docs/scaling.md

@@ -6,7 +6,7 @@ For running large workflows, you'll typically need to scale the controller to ma
 
 You cannot horizontally scale the controller.
 
-> v3.0
+> v3.0 and after
 
 As of v3.0, the controller supports having a hot-standby for [High Availability](high-availability.md#workflow-controller).
 

docs/suspend-template.md

@@ -1,5 +1,5 @@
 # Suspend Template
 
-> v2.1
+> v2.1 and after
 
 See [Suspending](walk-through/suspending.md).

docs/variables.md

@@ -49,7 +49,7 @@ args: [ "{{ inputs.parameters.message }}" ]
 
 ### Expression
 
-> Since v3.1
+> v3.1 and after
 
 The tag is substituted with the result of evaluating the tag as an expression.
 
@@ -170,7 +170,7 @@ sprig.trim(inputs.parameters['my-string-param'])
 
 ### HTTP Templates
 
-> Since v3.3
+> v3.3 and after
 
 Only available for `successCondition`
 

docs/workflow-events.md

@@ -1,8 +1,9 @@
 # Workflow Events
 
-> v2.7.2
+> v2.7.2 and after
 
-⚠️ Do not use Kubernetes events for automation. Events maybe lost or rolled-up.
+!!! Warning "Kubernetes events"
+    Do not use Kubernetes events for automation as they can be lost or rolled-up.
 
 We emit Kubernetes events on certain events.
 

docs/workflow-templates.md

@@ -110,7 +110,7 @@ spec:
 
 ### Adding labels/annotations to Workflows with `workflowMetadata`
 
-> 2.10.2 and after
+> v2.10.2 and after
 
 To automatically add labels and/or annotations to Workflows created from `WorkflowTemplates`, use `workflowMetadata`.
 
@@ -282,10 +282,10 @@ to pass in "live" arguments and reference other templates (those other templates
 
 This behavior has been problematic and dangerous. It causes confusion and has design inconsistencies.
 
-> 2.9 and after
-
 ### Create `Workflow` from `WorkflowTemplate` Spec
 
+> v2.9 and after
+
 You can create `Workflow` from `WorkflowTemplate` spec using `workflowTemplateRef`. If you pass the arguments to created `Workflow`, it will be merged with workflow template arguments.
 Here is an example for referring `WorkflowTemplate` as Workflow with passing `entrypoint` and `Workflow Arguments` to `WorkflowTemplate`
 
@@ -333,7 +333,7 @@ Then submit a workflow using one of those templates:
 argo submit https://raw.githubusercontent.com/argoproj/argo-workflows/main/examples/workflow-template/hello-world.yaml
 ```
 
-> 2.7 and after
+> v2.7 and after
 
 Then submit a `WorkflowTemplate` as a `Workflow`: