Harness Integration Upgrade Policy

Harness integration upgrade cadence, support policy, and tooling version expectations

Harness updates Continuous Delivery (CD) integrations on a regular cadence so connectors, CLIs, and plugins stay aligned with upstream tools. This topic explains the update cycle, how Harness defines support for Kubernetes and other integrations, and how release notes communicate impact.

---

What you will learn from this topic

• How quarterly integration updates relate to upstream tool release velocity

• How testing and quality assurance apply before an integration update ships

• How to read the tooling version matrix for connectors and plugins

• How Harness defines Kubernetes version support for managed and self-managed clusters

• Where to find release notes and impact assessment after an SDK, CLI, or integration update

---

Quarterly integration updates

Harness updates its integrations on a quarterly basis. The schedule follows the release velocity of the integrated tools. Routine updates bring newer features and fixes into the Harness integration layer so your pipelines can use current upstream capabilities.

---

Scope of tooling updates

Tooling updates apply across integrations, not only one product line. The goal is to keep supported integrations current with upstream releases that Harness has tested for the related deployment types.

---

Testing and quality assurance

Harness tests integration updates against the corresponding and impacted deployment types to reduce functional regressions. Testing focuses on preserving existing deployment behavior for supported versions listed in the matrix.

---

Tooling version matrix

The following table lists connector and integration versions from the prior published revision of this topic. Treat Supported Version as the Harness-supported baseline for planning, and confirm Latest Version against upstream release notes when you upgrade.

Connector	Integration	Supported Version	Latest Version	Upgrade Cycle
Kubernetes	Kubernetes	1.27.4	1.30.3	Quarterly
Helm	Helm	3.8.x	3.14.x	Quarterly
Tanzu	Tanzu	cf cli v7	cf cli v8	Quarterly
Terraform	Terraform	1.3.5	1.9.4	Quarterly
Terragrunt	Terragrunt	0.40.x	0.66.4	Quarterly
Serverless	Serverless.com plugin	3.x	4.x	Quarterly
Jenkins	Jenkins Build Step	2.440	2.471	Quarterly
GitOps	Argo CD	2.8.x	2.12.x	Quarterly
AWS	AWS SAM Plugin	1.84.0	1.121.0	Quarterly

---

Kubernetes maintenance FAQ

The following questions describe how Harness supports Kubernetes versions for CD integrations.

What Kubernetes versions does Harness support, and how is support maintained?

Harness officially supports the current stable Kubernetes minor release and the two previous minor releases, aligned with common cloud-vendor support windows. For example, when 1.30 is the current stable minor in that window, support covers 1.30, 1.29, and 1.28.

Kubernetes and Helm integrations receive quarterly maintenance, and can receive updates more often when upstream changes require it.

What about on-premises Kubernetes clusters that customers maintain themselves?

Versions outside the official support window are handled on a best-effort basis. That includes older minors such as 1.27, 1.26, down through 1.22.

For clusters older than 1.22, Harness aims to keep integrations backwards compatible where practical, but cannot guarantee behavior for every older Kubernetes release. Harness does not ship patches solely to keep unsupported Kubernetes versions working. The supported path is to upgrade the cluster.

Harness can surface installation or upgrade pre-flight checks during deployment that warn when the Kubernetes version is outside the support policy.

What does it mean to support a Kubernetes version?

Support means Harness does not intentionally introduce changes that break compatibility with the oldest minor still in the supported window. For example, Harness does not introduce a v1.30-only behavior if it breaks compatibility with v1.28 while v1.28 remains supported. When a newer minor enters the window and an older minor leaves it, compatibility with the dropped minor is no longer guaranteed.

If you run an unsupported Kubernetes version and hit a problem caused by incompatibility, upgrade the cluster. Harness does not issue a patch solely to support an older unsupported Kubernetes version.

---

Integration FAQs

Does Harness use SDKs for the cloud vendors?

Yes. Harness uses the AWS SDK, Google Cloud SDK, and Azure SDK for the related deployment paths.

---

Why routine updates matter

Keep the following outcomes in mind when you plan upgrades:

• Capabilities: Newer upstream releases expose features and fixes your pipelines can use after Harness validates the integration.

• Security: Older tool versions accumulate known vulnerabilities. Staying on supported integration versions reduces exposure from outdated CLIs and plugins.

• Performance: Upstream releases often include performance fixes that improve reliability of the integration path.

---

Release notes and impact assessment

When Harness updates an SDK, CLI, or integration, release notes describe the changes, benefits, and potential impact on existing workflows. Review those notes before you roll the update through lower environments.

---

Feedback

If an integration update causes unexpected behavior in your pipelines, contact Harness Support with the integration name, versions involved, and the deployment type.

---

Next steps

• CD and GitOps tutorials: Validate deployments after an integration upgrade.

• CD FAQs: Review related Continuous Delivery questions.

• Harness Support: Report integration regressions or request clarification on support windows.