tidy

helm · Aug 10, 2023 · 30af5d8 · 30af5d8
1 parent 305973b
commit 30af5d8
Showing 1 changed file with 2 additions and 2 deletions.
diff --git a/hips/hip-00XX.md b/hips/hip-00XX.md
@@ -12,7 +12,7 @@ status: "draft"
 <!-- A short (~200 word) description of the technical issue being addressed. -->
 Helm 3 introduced the [three-way strategic merge and patch](https://helm.sh/docs/faq/changes_since_helm2/#improved-upgrade-strategy-3-way-strategic-merge-patches) methology. Allowing Helm to update resources which may have been modified by other processes.
 
-Kubernetes now offers [Server-Side Apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/) (SSA)(GA since v1.22), that has serveral advantages over the client-side apply (CSA) methods that Helm, and e.g. Kubectl traditionally incorporated.
+Kubernetes now offers [Server-Side Apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/) (SSA), that has serveral advantages over the client-side apply (CSA) methods that Helm, and e.g. Kubectl traditionally incorporated.
 
 This HIP proposes enabling Helm to utilize Kubernete's Server-Side Apply for Helm resource management. But limits scope to incorporating SSA as an opt-in feature only. And defers removing / changing existing usaging of the (client-side) three-way strategic merge patch processes (without opt-in).
 
@@ -41,7 +41,7 @@ Due to the backwards compatibility concerns documented below, the decision was m
 
 Helm will add a new flag to the install, upgrade and rollback sub-commands: `--server-side=false|true|auto`, modelled after the like `kubectl` flag. And add a corresponding field to the respective install/upgrade/rollback SDK API objects. Helm will default to `false` for installs, retaining its existing behaviour. When `true`, Helm will submit resources to the Kubernetes API server with SSA enabled. When `auto`, Helm will default to CSA on installs (`false`), and for upgrades and rollbacks enable SSA based on the whether SSA was utilized for the prior operation (`auto`). The usage of SSA for a given release will be stored in the release's manifest.
 
-If the user attempts to use SSA with a cluster which does not support it (unlikely: SSA [went GA](https://kubernetes.io/blog/2021/08/06/server-side-apply-ga/) in Kubernetes 1.22), Helm should error.
+If the user attempts to use SSA with a cluster which does not support it (unlikely: SSA [went GA](https://kubernetes.io/blog/2021/08/06/server-side-apply-ga/) in Kubernetes v1.22), Helm should error.
 
 If a user deploys a chart with a new version of Helm with SSA enabled, then upgrades the chart with an older version of Helm. It is expected that the older Helm will be able to upgrade the chart with CSA. And the new manifest object will omit the indication of SSA usage from the releases manifest (and so upgrades with a SSA supporting version of Helm will not continue to use SSA by default).