Supported runtime and SDK releases

Runtime and SDK release support and upgrade policies

Introduction

This topic details the supported versions of Dapr releases, the upgrade policies and how deprecations and breaking changes are communicated in all Dapr repositories (runtime, CLI, SDKs, etc) at versions 1.x and above.

Dapr releases use MAJOR.MINOR.PATCH versioning. For example, 1.0.0.

A supported release means:

• A hoxfix patch is released if the release has a critical issue such as a mainline broken scenario or a security issue. Each of these are reviewed on a case by case basis.
• Issues are investigated for the supported releases. If a release is no longer supported, you need to upgrade to a newer release and determine if the issue is still relevant.

From the 1.8.0 release onwards three (3) versions of Dapr are supported; the current and previous two (2) versions. Typically these are MINORrelease updates. This means that there is a rolling window that moves forward for supported releases and it is your operational responsibility to remain up to date with these supported versions. If you have an older version of Dapr you may have to do intermediate upgrades to get to a supported version.

There will be at least 6 weeks between major.minor version releases giving users a 12 week (3 month) rolling window for upgrading.

Patch support is for supported versions (current and previous).

Build variations

The Dapr’s sidecar image is published to both GitHub Container Registry and Docker Registry. The default image contains all components. From version 1.11, Dapr also offers a variation of the sidecar image, containing only stable components.

• Default sidecar images: daprio/daprd:<version> or ghcr.io/dapr/daprd:<version> (for example ghcr.io/dapr/daprd:1.11.1)
• Sidecar images for stable components: daprio/daprd:<version>-stablecomponents or ghcr.io/dapr/daprd:<version>-stablecomponents (for example ghcr.io/dapr/daprd:1.11.1-stablecomponents)

On Kubernetes, the sidecar image can be overwritten for the application Deployment resource with the dapr.io/sidecar-image annotation. See more about Dapr’s arguments and annotations. The default ‘daprio/daprd:latest’ image is used if not specified.

Learn more about Dapr components’ certification lifecycle.

Supported versions

The table below shows the versions of Dapr releases that have been tested together and form a “packaged” release. Any other combinations of releases are not supported.

Upgrade paths

After the 1.0 release of the runtime there may be situations where it is necessary to explicitly upgrade through an additional release to reach the desired target. For example, an upgrade from v1.0 to v1.2 may need to pass through v1.1.

Note

Dapr only has a seamless guarantee when upgrading patch versions in a single minor version, or upgrading from one minor version to the next. For example, upgrading from v1.6.0 to v1.6.4 or v1.6.4 to v1.7.0 is guaranteed tested. Upgrading more than one minor version at a time is untested and treated as best effort.

The table below shows the tested upgrade paths for the Dapr runtime. Any other combinations of upgrades have not been tested.

General guidance on upgrading can be found for self hosted mode and Kubernetes deployments. It is best to review the target version release notes for specific guidance.

Upgrade on Hosting platforms

Dapr can support multiple hosting platforms for production. With the 1.0 release the two supported platforms are Kubernetes and physical machines. For Kubernetes upgrades see Production guidelines on Kubernetes

Supported versions of dependencies

Below is a list of software that the latest version of Dapr (v1.12.0) has been tested against.

Related links

• Read the Versioning Policy
• Read the Breaking Changes and Deprecation Policy

Last modified October 12, 2023: Update config.toml (#3826) (0ffc2e7)