支持和版本

• 1: 版本控制策略
• 2: 支持的运行时和 SDK 版本
• 3: 重大变更与弃用
• 4: 报告安全问题
• 5: 预览功能
• 6: Alpha and Beta APIs

1 - 版本控制策略

简介

Dapr 通过版本控制方案，为运行时、API 和组件的未来变更而设计。本主题描述了 API、组件清单（如组件）和 Github 仓库的版本控制方案和策略。

版本控制

版本控制是为计算机软件的特定状态分配唯一版本名称或唯一版本号的过程。

• 版本控制提供兼容性、显式的变更控制以及处理变更（特别是重大变更）的能力。
• Dapr 努力保持向后兼容。如果需要重大变更，将提前公告。
• 弃用功能会跨越多个发布版本进行，新旧功能会并排工作。

版本控制适用于以下 Dapr 仓库：dapr、CLI、稳定语言 SDK、dashboard、components-contrib、quickstarts、helm-charts 和 documentation。

Dapr 具有以下版本控制方案：

• Dapr HTTP API 使用 MAJOR.MINOR 进行版本控制
• Dapr GRPC API 使用 MAJOR 进行版本控制
• 发布版本（包括 dapr、CLI、SDK 和 Helm Chart 的 GitHub 仓库）使用 MAJOR.MINOR.PATCH
• 文档和 Quickstarts 仓库使用 Dapr 运行时仓库的版本控制
• Dapr Components 在 components-contrib GitHub 仓库中使用 MAJOR
• Dapr Manifests 使用 MAJOR.MINOR。这些包括订阅和配置。

请注意，Dapr API、二进制发布版本（运行时、CLI、SDK）和组件都是相互独立的。

Dapr HTTP API

Dapr HTTP API 根据这些 REST API 指南 进行版本控制。

基于这些指南：

• 当预期旧版本将被弃用时，API 的 MAJOR 版本会递增。任何此类弃用都将被沟通，并提供升级路径。
• 对于任何其他更改，MINOR 版本可能会递增。例如，对发送到 API 的消息的 JSON 模式进行更改。
• API 重大变更的定义可以查看这里。
• 实验性 API 包含"alpha"后缀以表示其 alpha 状态。例如 v1.0alpha、v2.0alpha 等。

Dapr 运行时

Dapr 发布版本使用 MAJOR.MINOR.PATCH 版本控制。例如 1.0.0。阅读支持的发布版本以了解有关发布版本控制的更多信息。

Helm Charts

helm-charts 仓库中的 Helm charts 使用 Dapr 运行时版本控制。Helm charts 用于 Kubernetes 部署

语言 SDK、CLI 和 dashboard

Dapr 语言 SDK、CLI 和 dashboard 与 Dapr 运行时独立版本控制，可以按不同的时间表发布。查看此表格以显示 SDK、CLI、dashboard 和运行时版本之间的兼容性。运行时的每个新版本都会列出相应的受支持 SDK、CLI 和 Dashboard。

SDK、CLI 和 Dashboard 的版本控制遵循 MAJOR.MINOR.PATCH 格式。当 SDK 中存在不向后兼容的更改时（例如，更改客户端方法上的参数），主版本会递增。次版本会为新功能和错误修复进行更新，而在错误或安全热修复的情况下会递增补丁版本。

SDK 中的示例和示例代码与该仓库一起进行版本控制。

组件

组件在 components-contrib 仓库中实现，遵循 MAJOR 版本控制方案。组件的版本遵守主版本（vX），补丁和非重大变更会添加到最新的主版本中。当组件接口中存在不向后兼容的更改时，版本会递增，例如，更改状态存储接口中的现有方法。

components-contrib 仓库发布版本是其内部所有组件的统一版本。也就是说，components-contrib 仓库发布版本由其中所有组件的 schema 组成。如果没有组件更改，Dapr 的新版本并不意味着 components-contrib 有新发布版本。

注意：组件具有生产使用生命周期状态：Alpha、Beta 和 Stable。这些状态与其版本控制无关。受支持组件的表格显示了它们的版本和状态。

• 状态存储组件列表
• 发布订阅组件列表
• 绑定组件列表
• 密钥存储组件列表
• 配置存储组件列表
• 锁组件列表
• 加密组件列表
• 中间件组件列表

有关组件版本控制的更多信息，请阅读组件的版本 2 及更高版本

组件 schema

组件 YAML 的版本控制有两种形式：

• 组件清单的版本控制。apiVersion
• 组件实现的版本。.spec.version

组件清单包含 .spec.metadata 字段中实现的 schema，.type 字段表示实现

请参阅下面示例中的注释：

apiVersion: dapr.io/v1alpha1 # <-- 这是组件清单的版本
kind: Component
metadata:
  name: pubsub
spec:
  version: v1 # <-- 这是 pubsub.redis schema 实现的版本
  type: pubsub.redis
  metadata:
  - name: redisHost
    value: redis-master:6379
  - name: redisPassword
    value: general-kenobi

组件清单版本

组件 YAML 清单使用 dapr.io/v1alpha1 进行版本控制。

组件实现版本

组件实现的版本由 .spec.version 字段确定，如上面的示例所示。.spec.version 字段在 schema 实例中是必需的，如果不存在，组件将无法加载。对于 Dapr 1.0.0 的发布版本，所有组件都标记为 v1。组件实现版本仅在不向后兼容的更改时递增。

组件弃用

组件弃用将提前两个（2）发布版本宣布。组件弃用会导致组件版本的主版本更新。2 个发布版本后，组件将从 Dapr 运行时中注销，尝试加载它将抛出致命异常。

组件弃用和移除将在发布说明中宣布。

Quickstarts 和示例

Quickstarts 仓库中的 Quickstarts 使用运行时版本控制，相应版本的表格位于示例仓库的首页。用户应仅使用与正在运行的运行时版本对应的 Quickstarts。

Samples 仓库中的示例根据示例维护者的情况逐个进行版本控制。与运行时发布版本相差甚远（落后多个版本）或超过 1 年未维护的示例将被删除。

相关链接

• 阅读支持的发布版本
• 阅读重大变更和弃用策略

2 - 支持的运行时和 SDK 版本

简介

本主题详细介绍了 Dapr 版本的支持版本、升级策略，以及如何在所有 Dapr 仓库（运行时、CLI、SDK 等）的 1.x 及以上版本中传达弃用和重大更改。

Dapr 版本使用 MAJOR.MINOR.PATCH 版本控制。例如，1.0.0。

支持的版本意味着：

• 如果版本存在关键问题（如主线中断场景或安全问题），则会发布热修复补丁。每个问题都会根据具体情况进行审查。
• 会对支持的版本调查问题。如果版本不再受支持，您需要升级到较新的版本并确定问题是否仍然相关。

从 1.8.0 版本开始，支持三个（3）版本的 Dapr；当前版本和前两个（2）版本。通常是 MINOR 版本更新。这意味着支持的版本有一个向前移动的滚动窗口，保持与这些受支持版本的最新状态是您的运营责任。如果您使用的是较旧版本的 Dapr，您可能需要进行中间升级才能到达受支持的版本。

主要.次要版本发布之间至少有 13 周（3 个月）的时间，为用户从非支持版本升级提供至少 9 个月的滚动窗口。有关发布流程的更多详细信息，请阅读发布周期和节奏

补丁支持适用于支持的版本（当前和先前版本）。

构建变体

Dapr 的边车镜像发布到 GitHub Container Registry 和 Docker Registry。默认镜像包含所有组件。从 1.11 版本开始，Dapr 还提供了一种边车镜像变体，仅包含稳定组件。

• 默认边车镜像：daprio/daprd:<version> 或 ghcr.io/dapr/daprd:<version>（例如 ghcr.io/dapr/daprd:1.11.1）
• 稳定组件边车镜像：daprio/daprd:<version>-stablecomponents 或 ghcr.io/dapr/daprd:<version>-stablecomponents（例如 ghcr.io/dapr/daprd:1.11.1-stablecomponents）

在 Kubernetes 上，可以使用 dapr.io/sidecar-image 注解覆盖应用程序 Deployment 资源的边车镜像。有关 Dapr 的参数和注解 的更多信息。如果未指定，则使用默认的 ‘daprio/daprd:latest’ 镜像。

了解有关 Dapr 组件认证生命周期 的更多信息。

支持的版本

下表显示已经过一起测试并构成"打包"版本的 Dapr 版本。不支持任何其他版本组合。

SDK 兼容性

除安全问题所需的更改外，SDK 和运行时承诺不做重大更改。所有重大更改（如有）都会在发布说明中宣布。

SDK 和运行时向前兼容性
较新的 Dapr SDK 支持 Dapr 运行时的最新版本和前两个版本（N-2）。

SDK 和运行时向后兼容性
对于新的 Dapr 运行时，支持当前的 SDK 版本和前两个版本（N-2）。

升级路径

运行时 1.0 版本发布后，可能需要通过其他版本显式升级才能达到所需的目标版本。例如，从 v1.0 升级到 v1.2 可能需要通过 v1.1。

下表显示了 Dapr 运行时的已测试升级路径。任何其他升级组合均未经过测试。

有关升级的一般指南，请参阅自托管模式和 Kubernetes部署。最好查看目标版本的发布说明以获取具体指南。

在托管平台上升级

Dapr 可以支持生产环境的多个托管平台。在 1.0 版本中，两个受支持的平台是 Kubernetes 和物理机。有关 Kubernetes 升级，请参阅 Kubernetes 上的生产指南

依赖项的受支持版本

以下是最新版本的 Dapr（v1.18.0）已测试的软件列表。

相关链接

• 阅读版本控制策略
• 阅读重大更改和弃用策略

3 - 重大变更与弃用

重大变更

重大变更定义为在升级到下一个稳定次要版本的 Dapr 工件（SDK、CLI、运行时等）后，对以下任何内容的更改导致现有的第三方应用程序或脚本出现编译错误或不良运行时行为：

• 代码行为
• 架构
• 默认配置值
• 命令行参数
• 发布的指标
• Kubernetes 资源模板
• 公共可访问的 API
• 公共可见的 SDK 接口、方法、类或属性

重大变更可以立即应用于以下情况：

• 尚未达到 1.0.0 版本的项目
• 预览功能
• Alpha API
• SDK 中的预览或 Alpha 接口、类、方法或属性
• Alpha 或 Beta 阶段的 Dapr 组件
• github.com/dapr/components-contrib 的接口
• 文档和博客中的 URL
• 例外情况，即必须修复严重错误或安全漏洞。

应用重大变更的流程

应用重大变更有一个流程：

1. 必须在某个版本中发布弃用通知。
2. 重大变更将在宣布弃用的版本之后的两个（2）版本中应用。
   • 例如，功能 X 在 1.0.0 版本说明中宣布弃用，随后将在 1.2.0 中移除。

弃用

弃用可应用于：

1. API，包括 alpha API
2. 预览功能
3. 组件
4. CLI
5. 可能导致安全漏洞的功能

弃用内容会出现在版本说明中名为 “Deprecations” 的部分下，该部分指示：

• 将来不再支持已弃用功能的时间点。例如版本 x.y.z。这至少在两个（2）版本之前。
• 如果适用，在版本说明中记录用户必须采取的任何步骤来修改其代码、操作等。

在宣布未来的重大变更后，变更将在 2 个版本或 6 个月后生效，以较晚者为准。已弃用的功能应响应警告，但除此之外不执行任何操作。

已宣布的弃用

相关链接

• 阅读版本控制策略
• 阅读支持的版本

4 - 报告安全问题

Dapr 项目和维护者将安全作为我们运营和设计软件的核心关注点。从 Dapr 二进制文件到 GitHub 发布流程，我们采取了众多措施来确保用户应用程序和数据的安全。有关 Dapr 安全功能的更多信息，请访问安全页面。

涵盖的仓库和问题

当我们说"Dapr 中的安全漏洞"时，这指的是 dapr GitHub 组织下任何仓库中的安全问题。

此报告流程仅适用于 Dapr 项目本身的安全问题，不适用于使用 Dapr 的应用程序或不影响安全的问题。

如果问题无法通过更改上述涵盖的仓库之一来解决，建议在相应的仓库中创建 GitHub issue 或在 Discord 中提出问题。

如果您不确定，请谨慎行事，在通过 GitHub、Discord 或其他渠道提出问题之前，先使用报告流程与我们联系。

明确不涵盖：漏洞扫描器报告

我们不接受仅仅是复制粘贴漏洞扫描工具输出的报告，除非已经做了具体工作来确认工具报告的漏洞在 Dapr 中确实存在，包括 CLI、Dapr SDK、components-contrib 仓库或 Dapr 组织下的任何其他仓库。

我们自己使用这些工具，并尝试根据它们产生的输出采取行动。然而，我们倾向于发现，当这些报告发送到我们的安全邮件列表时，它们几乎总是代表误报，因为这些工具倾向于检查库的存在，而不考虑库在上下文中如何使用。

如果我们收到的报告似乎只是来自扫描器的漏洞列表，我们保留忽略它的权利。

当工具生成的漏洞标识符不可公开可见或以某种方式为专有时，这尤其适用。我们可以查找 CVE 或其他公开可用的标识符以获取更多详细信息，但无法对专有标识符执行相同的操作。

安全联系人

有权阅读您的安全报告的人员列在 maintainers.md 中。

报告流程

1. 用英语描述问题，最好提供一些允许重现问题的示例配置或代码。解释您为什么认为这是 Dapr 中的安全问题。
2. 将该信息放入电子邮件中。使用描述性标题。
3. 发送电子邮件至 Security (security@dapr.io)

响应

响应时间可能会受到周末、节假日、休息或时区差异的影响。尽管如此，维护者团队会尽快回复，理想情况下在 3 个工作日内。

如果团队确认报告的问题确实是 Dapr 项目中的安全漏洞，维护者团队中至少有两名成员会尽快讨论下一步措施，理想情况下在 24 小时内。

一旦团队确定报告确实是真正的漏洞，团队中的一员会向报告者回复，确认问题并建立披露时间表，这应该尽快完成。

分类、响应、修复和公告应在 30 天内完成。

5 - 预览功能

Dapr 中的预览功能在首次发布时被视为实验性功能。

运行时预览功能需要显式选择加入才能使用。运行时选择加入是在 Dapr 应用配置中的预览设置功能中指定的。有关更多信息，请参阅如何：启用预览功能。

对于 CLI，无需显式选择加入，只需使用该功能首次引入的版本即可。

当前预览功能

6 - Alpha and Beta APIs

Alpha 版 API

Beta 版 API

当前没有 beta 版 API。

相关链接

了解有关 Alpha、Beta 和 Stable 生命周期阶段的更多信息。