Merge pull request #90326 from mramendi/RHDEVDOCS-6395

RHDEVDOCS 6395 Document the fact that older versioned tasks and step actions can be deleted

Author: jeana-redhat

modules/op-resolver-tasks-step-actions-about.adoc

@@ -7,11 +7,11 @@
 
 = About non-versioned and versioned tasks and step actions
 
-The `openshift-pipelines` namespace includes versioned tasks and step actions alongside standard non-versioned tasks and step actions. For example, installing the {pipelines-title} Operator v1.16 creates the following items:
+The `openshift-pipelines` namespace includes versioned tasks and step actions alongside standard non-versioned tasks and step actions. For example, installing the {pipelines-title} Operator version 1.18 creates the following items:
 
-* `buildah-1-16-0` versioned task
+* `buildah-1-18-0` versioned task
 * `buildah` non-versioned task
-* `git-clone-1-16-0` versioned `StepAction` definition
+* `git-clone-1-18-0` versioned `StepAction` definition
 * `git-clone` non-versioned `StepAction` definition
 
 Non-versioned and versioned tasks and step actions have the same metadata, behavior, and specifications, including `params`, `workspaces`, and `steps`. However, they behave differently when you disable them or upgrade the Operator.
@@ -25,20 +25,20 @@ Before adopting non-versioned or versioned tasks and step actions as a standard
 |  | Advantages | Disadvantages
 
 s| Non-versioned tasks and step actions
-a| 
-* If you prefer deploying pipelines with the latest updates and bug fixes, use non-versioned tasks and step actions. 
-* Upgrading the Operator upgrades the non-versioned tasks and step actions, which consumes fewer resources than multiple versioned tasks and step actions.  
-a| 
-* If you deploy pipelines that use non-versioned tasks and step actions, they might break after an Operator upgrade if the automatically upgraded tasks and step actions are not backward-compatible. 
+a|
+* If you prefer deploying pipelines with the latest updates and bug fixes, use non-versioned tasks and step actions.
+* Upgrading the Operator upgrades the non-versioned tasks and step actions, which consumes fewer resources than multiple versioned tasks and step actions.
+a|
+* If you deploy pipelines that use non-versioned tasks and step actions, they might break after an Operator upgrade if the automatically upgraded tasks and step actions are not backward-compatible.
 
 s| Versioned tasks and step actions
-a| 
-* If you prefer stable pipelines in production, use versioned tasks and step actions. 
-* Earlier versions are retained on the cluster even after the later version of a task or step action is installed. You can continue using the earlier versions. 
-a| 
+a|
+* If you prefer pipelines in production that do not change after a version update, use versioned tasks and step actions.
+* When you install a new version of the Operator, the versioned tasks and step actions from the current minor version and the immediate previous minor version are retained.
+a|
 * If you continue using the earlier versions, you might miss the latest features and critical security updates.
-* The earlier versions that are not operational consume cluster resources.  
-* After an upgrade, the Operator cannot manage the earlier versioned tasks and step actions. You can delete the earlier versions manually, but you cannot restore them.  
+* After an upgrade, the Operator cannot manage the earlier versioned tasks and step actions. If you delete the earlier versions manually, you cannot restore them.
+* After an upgrade, the Operator can delete versioned tasks and step actions from versions earlier than the previous minor release. When you install a new version of {openshift-pipelines} and the versioned tasks or step actions from an earlier version are deleted, pipelines that use the versioned tasks from the earlier version stop working.
 |
 |===
 
@@ -52,14 +52,11 @@ Non-versioned and versioned tasks and step actions have different naming convent
 
 s| Non-versioned tasks and step actions
 
-| Non-versioned tasks and step actions only contain the name of the task or step action. For example, the name of the non-versioned task of Buildah installed with Operator v1.16 is `buildah`. 
-| When you upgrade the Operator, it updates the non-versioned tasks and step actions with the latest changes. The name remains unchanged. 
+| Non-versioned tasks and step actions only contain the name of the task or step action. For example, the name of the non-versioned task of Buildah installed with Operator v1.18 is `buildah`.
+| When you upgrade the Operator, it updates the non-versioned tasks and step actions with the latest changes. The name remains unchanged.
 
 s| Versioned tasks and step actions
 
-| Versioned tasks and step actions contain the name, followed by the version as a suffix. For example, the name of the versioned task of Buildah installed with Operator v1.16 is `buildah-1-16-0`.
-| Upgrading the Operator installs the latest version of versioned tasks and step actions and retains the earlier version. The latest version corresponds to the upgraded Operator. For example, installing Operator 1.17 installs the `git-clone-1-17-0` step action and retains the `git-clone-1-16-0` step action. 
+| Versioned tasks and step actions contain the name, followed by the version as a suffix. For example, the name of the versioned task of Buildah installed with Operator v1.18 is `buildah-1-18-0`.
+| Upgrading the Operator installs the latest version of versioned tasks and step actions, retains the immediate previous version, and deletes the earlier versions. The latest version corresponds to the upgraded Operator. For example, installing Operator 1.18 installs the `buildah-1-18-0` task, retains the `buildah-1-17-0` task, and deletes earlier versions such as `buildah-1-16-0`.
 |===
-
-
-