apache/airflow

# Apache Airflow | Category | Badges | |------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | License | [](https://www.apache.org/licenses/LICENSE-2.0.txt) | | PyPI | [](https://badge.fury.io/py/apache-airflow) [](https://pypi.org/project/apache-airflow/) [](https://pypi.org/project/apache-airflow/) | | Containers | [](https://hub.docker.com/r/apache/airflow) [](https://hub.docker.com/r/apache/airflow) [](https://artifacthub.io/packages/search?repo=apache-airflow) | | Community | [](https://github.com/apache/airflow/graphs/contributors) [](https://s.apache.org/airflow-slack)  [](https://insights.linuxfoundation.org/project/apache-airflow) | | Dev tools | [](https://github.com/j178/prek) | | Version | Build Status | |---------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------| | Main | [](https://github.com/apache/airflow/actions) | | 3.x | [](https://github.com/apache/airflow/actions) | | 2.x | [](https://github.com/apache/airflow/actions) | [Apache Airflow](https://airflow.apache.org/docs/apache-airflow/stable/)（或简称 Airflow）是一个用于以编程方式编写、调度和监控工作流的平台。 当工作流被定义为代码时，它们变得更具可维护性、可进行版本控制、可测试且易于协作。 使用 Airflow 来编写用于编排任务的工作流。Airflow 调度器在遵循指定依赖关系的同时，在一组 worker 上执行您的任务。丰富的命令行实用程序使得对 DAG 执行复杂的修改变得轻而易举。丰富的用户界面使您可以轻松可视化生产环境中运行的管道、监控进度并在需要时排查问题。 **目录** - [项目侧重点](#project-focus) - [原则](#principles) - [需求](#requirements) - [快速入门](#getting-started) - [从 PyPI 安装](#installing-from-pypi) - [安装](#installation) - [官方源代码](#official-source-code) - [便捷包](#convenience-packages) - [用户界面](#user-interface) - [语义化版本控制](#semantic-versioning) - [版本生命周期](#version-life-cycle) - [对 Python 和 Kubernetes 版本的支持](#support-for-python-and-kubernetes-versions) - [参考 Airflow 镜像的基础操作系统支持](#base-os-support-for-reference-airflow-images) - [Airflow 的依赖项管理策略](#approach-to-dependencies-of-airflow) - [贡献](#contributing) - [投票政策](#voting-policy) - [谁在使用 Apache Airflow？](#who-uses-apache-airflow) - [谁在维护 Apache Airflow？](#who-maintains-apache-airflow) - [下一个版本包含什么？](#what-goes-into-the-next-release) - [我可以在演示文稿中使用 Apache Airflow 的徽标吗？](#can-i-use-the-apache-airflow-logo-in-my-presentation) - [链接](#links) - [赞助商](#sponsors) ## 项目侧重点 Airflow 最适合处理主要是静态且变化缓慢的工作流。当 DAG 结构从一次运行到下一次运行保持相似时，它能明确工作单元和连续性。其他类似的项目包括 [Luigi](https://github.com/spotify/luigi)、[Oozie](https://oozie.apache.org/) 和 [Azkaban](https://azkaban.github.io/)。 Airflow 通常用于处理数据，但其观点是任务理想情况下应该是幂等的（即任务的结果将是相同的，并且不会在目标系统中创建重复数据），并且不应在任务之间传递大量数据（尽管任务可以使用 Airflow 的 [XCom 功能](https://airflow.apache.org/docs/apache-airflow/stable/concepts/xcoms.html)传递元数据）。对于大批量、数据密集型的任务，最佳做法是将其委托给专门从事此类工作的外部服务。 Airflow 不是一个流处理解决方案，但它常用于处理实时数据，以批处理方式从流中提取数据。 ## 原则 - **动态**：流水线以代码定义，支持动态 DAG 生成和参数化。 - **可扩展**：Airflow 框架包含广泛的内置算子，并可根据您的需求进行扩展。 - **灵活**：Airflow 利用 [**Jinja**](https://jinja.palletsprojects.com) 模板引擎，允许丰富的自定义。 ## 需求 Apache Airflow 的测试环境： | | 主版本 (dev) | 稳定版本 (3.1.7) | 稳定版本 (2.11.1) | |------------|------------------------------------|------------------------|------------------------------| | Python | 3.10, 3.11, 3.12, 3.13 | 3.10, 3.11, 3.12, 3.13 | 3.10, 3.11, 3.12 | | Platform | AMD64/ARM64 | AMD64/ARM64 | AMD64/ARM64(\*) | | Kubernetes | 1.30, 1.31, 1.32, 1.33, 1.34, 1.35 | 1.30, 1.31, 1.32, 1.33 | 1.26, 1.27, 1.28, 1.29, 1.30 | | PostgreSQL | 14, 15, 16, 17, 18 | 13, 14, 15, 16, 17 | 12, 13, 14, 15, 16 | | MySQL | 8.0, 8.4, Innovation | 8.0, 8.4, Innovation | 8.0, Innovation | | SQLite | 3.15.0+ | 3.15.0+ | 3.15.0+ | \* 实验性 **注意**：MariaDB 未经过测试/不推荐使用。 **注意**：SQLite 用于 Airflow 测试。请勿在生产环境中使用它。我们建议在本地开发中使用最新稳定版本的 SQLite。 **注意**：Airflow 目前可在符合 POSIX 标准的操作系统上运行。对于开发，它定期在相当现代的 Linux 发行版和最新版本的 macOS 上进行测试。 在 Windows 上，您可以通过 WSL2 (Windows Subsystem for Linux 2) 或 Linux 容器来运行它。 添加 Windows 支持的工作通过 [#10388](https://github.com/apache/airflow/issues/10388) 进行跟踪，但这并不是高优先级。您应该只使用基于 Linux 的发行版作为“生产”执行环境，因为这是唯一受支持的环境。在我们的 CI 测试中使用的唯一发行版，以及[社区管理的 DockerHub 镜像](https://hub.docker.com/p/apache/airflow)中使用的唯一发行版是 `Debian Bookworm`。 ## 快速入门 请访问官方 Airflow 网站文档（最新**稳定**版本）以获取有关[安装 Airflow](https://airflow.apache.org/docs/apache-airflow/stable/installation/)、[快速入门](https://airflow.apache.org/docs/apache-airflow/stable/start.html)或通过更完整的[教程](https://airflow.apache.org/docs/apache-airflow/stable/tutorial/)进行学习的帮助。 有关 Airflow 改进提案 的更多信息，请访问 [Airflow Wiki](https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals)。 有关依赖项目（如 Provider 分发包、Docker 镜像、Helm Chart）的文档，您可以在[文档索引](https://airflow.apache.org/docs/)中找到。 ## 从 PyPI 安装 我们将 Apache Airflow 作为 `apache-airflow` 包发布在 PyPI 上。然而，安装它有时可能会比较棘手，因为 Airflow 既是库又是应用程序。库通常保持其依赖项开放，而应用程序通常将其固定，但我们应该同时做到既不固定又固定。我们决定保持我们的依赖项尽可能开放（在 `pyproject.toml` 中），以便用户可以根据需要安装不同版本的库。这意味着 `pip install apache-airflow` 有时可能无法工作，或者会产生不可用的 Airflow 安装。 然而，为了实现可重复的安装，我们在孤立的 `constraints-main` 和 `constraints-2-0` 分支中保留了一组“已知可工作”的约束文件。我们针对每个主要/次要 Python 版本分别保留这些“已知可工作”的约束文件。 在从 PyPI 安装 Airflow 时，您可以将它们用作约束文件。请注意，您必须在 URL 中指定正确的 Airflow 标签/版本/分支和 Python 版本。 1. 仅安装 Airflow： 虽然可以使用 [Poetry](https://python-poetry.org) 或 [pip-tools](https://pypi.org/project/pip-tools) 等工具安装 Airflow，但它们与 `pip` 的工作流程不同——尤其是在约束与需求管理方面。 目前不支持通过 `Poetry` 或 `pip-tools` 进行安装。 如果您希望使用这些工具安装 Airflow，则应使用约束文件，并将其转换为您工具所需的适当格式和工作流程。 ``` pip install 'apache-airflow==3.1.7' \ --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-3.1.7/constraints-3.10.txt" ``` 2. 使用 extras 安装（例如 postgres, google） ``` pip install 'apache-airflow[postgres,google]==3.1.7' \ --constraint "https://raw.githubusercontent.com/apache/airflow/constraints-3.1.7/constraints-3.10.txt" ``` 有关安装 Provider 分发包的信息，请查看 [providers](http://airflow.apache.org/docs/apache-airflow-providers/index.html)。 ## 安装 有关设置本地开发环境和安装 Apache Airflow 的详细说明，请参阅 [INSTALLING.md](INSTALLING.md) 文件。 ## 官方源代码 Apache Airflow 是一个 [Apache Software Foundation](https://www.apache.org) (ASF) 项目，我们的官方源代码发布： - 遵循 [ASF 发布策略](https://www.apache.org/legal/release-policy.html) - 可从 [ASF 分发目录](https://downloads.apache.org/airflow)下载 - 由发布经理进行加密签名 - 在[发布审批流程](https://www.apache.org/legal/release-policy.html#release-approval)期间由 PMC 成员正式投票通过 遵循 ASF 规则，发布的源代码包必须足以让用户构建和测试该版本，前提是他们有权访问适当的平台和工具。 ## 便捷包 还有其他安装和使用 Airflow 的方法。这些是“便捷”方法——它们不是 `ASF 发布策略` 所述的“官方发布”，但不想自己构建软件的用户可以使用它们。 这些是人们安装 Airflow 的最常见方式，按顺序排列： - [PyPI 发布](https://pypi.org/project/apache-airflow/)，使用标准 `pip` 工具安装 Airflow - [Docker 镜像](https://hub.docker.com/r/apache/airflow)，通过 `docker` 工具安装 airflow，在 Kubernetes、Helm Charts、`docker-compose`、`docker swarm` 等环境中使用它们。您可以在[最新文档](https://airflow.apache.org/docs/docker-stack/index.html)中阅读有关使用、自定义和扩展镜像的更多信息， [images](https://airflow.apache.org/docs/docker-stack/index.html) 文档中了解内部细节。 - [GitHub 上的标签](https://github.com/apache/airflow/tags)，用于检索通过 git 生成官方源代码包所用的 git 项目源代码 所有这些工件都不是官方发布，但它们是使用官方发布的源代码准备的。 其中一些工件是“开发版”或“预发布版”，根据 ASF 策略，它们已被明确标记为此类。 ## 用户界面 - **Dags**：环境中所有 DAG 的概览。  - **Assets**：具有依赖关系的 Assets 概览。  - **Grid**：跨越时间的 DAG 网格表示。  - **Graph**：特定运行的 DAG 依赖关系及其当前状态的可视化。  - **Home**：Airflow 环境的摘要统计信息。  - **Backfill**：对特定日期范围的 DAG 进行回填。  - **Code**：快速查看 DAG 源代码的方式。  ## 语义化版本控制 自 Airflow 2.0.0 起，我们对所有发布的包支持严格的 [SemVer](https://semver.org/) 方法。 我们商定了一些特定规则，定义了不同包的版本控制细节： * **Airflow**：SemVer 规则仅适用于核心 airflow（不包括对 Provider 的任何更改）。 更改 Airflow 依赖项的版本限制本身不是破坏性更改。 * **Airflow Providers**：SemVer 规则仅适用于特定 Provider 代码中的更改。 包的 SemVer MAJOR 和 MINOR 版本独立于 Airflow 版本。 例如，`google 4.1.0` 和 `amazon 3.1.1` Provider 可以愉快地与 `Airflow 2.1.2` 一起安装。如果 Provider 和 Airflow 包之间存在跨依赖限制，它们在 Provider 中作为 `install_requires` 限制出现。我们旨在保持 Provider 与所有先前发布的 Airflow 2 版本的向后兼容性，但有时会有破坏性更改，可能导致部分或所有 Provider 指定最低 Airflow 版本。 * **Airflow Helm Chart**：SemVer 规则仅适用于 Chart 中的更改。Chart 的 SemVer MAJOR 和 MINOR 版本独立于 Airflow 版本。我们旨在保持 Helm Chart 与所有已发布 Airflow 2 版本的向后兼容性，但某些新功能可能仅从特定的 Airflow 版本开始才能使用。但是，我们可能会限制 Helm Chart 依赖于最低 Airflow 版本。 * **Airflow API 客户端**：其版本控制独立于 Airflow 版本。它们遵循自己的 SemVer 规则进行破坏性更改和新功能开发——例如，这允许我们更改生成客户端的方式。 ## 版本生命周期 Apache Airflow 版本生命周期： | Version | Current Patch/Minor | State | First Release | Limited Maintenance | EOL/Terminated | |-----------|-----------------------|---------------------|-----------------|-----------------------|------------------| | 3 | 3.1.7 | Maintenance | Apr 22, 2025 | TBD | TBD | | 2 | 2.11.1 | Limited maintenance | Dec 17, 2020 | Oct 22, 2025 | Apr 22, 2026 | | 1.10 | 1.10.15 | EOL | Aug 27, 2018 | Dec 17, 2020 | June 17, 2021 | | 1.9 | 1.9.0 | EOL | Jan 03, 2018 | Aug 27, 2018 | Aug 27, 2018 | | 1.8 | 1.8.2 | EOL | Mar 19, 2017 | Jan 03, 2018 | Jan 03, 2018 | | 1.7 | 1.7.1.2 | EOL | Mar 28, 2016 | Mar 19, 2017 | Mar 19, 2017 | 有限支持版本仅获得安全性和关键错误修复支持。 EOL 版本将不会获得任何修复或支持。 我们始终建议所有用户运行所使用的任何主要版本的最新可用次要版本。 我们**强烈**建议在最早方便的时间且在 EOL 日期之前升级到最新的 Airflow 主要版本。 ## 对 Python 和 Kubernetes 版本的支持 自 Airflow 2.0 起，我们商定了遵循的 Python 和 Kubernetes 支持规则。 它们基于 Python 和 Kubernetes 的官方发布时间表，这些在 [Python Developer's Guide](https://devguide.python.org/#status-of-python-branches) 和 [Kubernetes version skew policy](https://kubernetes.io/docs/setup/release/version-skew-policy/) 中有很好的总结。 1. 当 Python 和 Kubernetes 版本到达 EOL 时，我们将不再支持它们。除了 Kubernetes，如果两个主要云提供商仍然提供支持，则该版本仍受 Airflow 支持。我们在 EOL 日期后立即在 main 分支中放弃对这些 EOL 版本的支持，并且当我们发布 Airflow 的第一个新 MINOR 版本（或 MAJOR 版本，如果没有新的 MINOR 版本）时，它实际上会被移除。例如，对于 Python 3.10，这意味着我们将在 2023 年 6 月 27 日之后立即在 main 分支中放弃支持，之后发布的第一个 Airflow MAJOR 或 MINOR 版本将不再包含它。 2. 在 Python/Kubernetes 新版本正式发布后，我们会在 main 分支中支持它们，一旦我们在 CI 管道中使其工作（由于依赖项大多需要时间跟上新的 Python 版本，这可能不会立即实现），我们将根据工作的 CI 设置发布新镜像/在 Airflow 中提供支持。 3. 此政策是尽力而为的，这意味着如果情况需要，我们可能会提前终止支持。 ## 参考 Airflow 镜像的基础操作系统支持 Airflow 社区提供方便打包的容器镜像，每当我们发布 Apache Airflow 版本时都会发布这些镜像。这些镜像包含： * 基础操作系统和安装 Airflow 所需的软件包（稳定的 Debian OS） * 在 Airflow 发布的 MINOR 版本发布时受支持的基础 Python 安装版本（例如，2.3 和 2.2 系列可能有不同的版本） * 连接到受支持数据库所需的库（同样，受支持的数据库集合取决于 Airflow 的 MINOR 版本） * 预定义的一组流行的 Provider（详情请参见 [Dockerfile](https://raw.githubusercontent.com/apache/airflow/main/Dockerfile)）。 * 构建您自己的自定义镜像的可能性，用户可以在其中选择自己的 Provider 和库集合（参见 [构建镜像](https://airflow.apache.org/docs/docker-stack/build.html)） * 将来 Airflow 可能还会支持“slim”版本，其中不安装 Provider 和数据库客户端 基础操作系统镜像的版本是 Debian 的稳定版本。Airflow 支持使用所有当前活动的稳定版本——只要所有 Airflow 依赖项支持构建，并且我们为构建和测试该操作系统版本设置了 CI 管道。在大约前一个稳定版本的操作系统定期支持结束前 6 个月，Airflow 会将发布的镜像切换为使用最新支持的操作系统版本。 例如，从 ``Debian Bullseye`` 到 ``Debian Bookworm`` 的切换已在 2023 年 10 月 2.8.0 版本发布前实施，并且从 Airflow 2.10.0 开始，``Debian Bookworm`` 将是唯一受支持的选项。 用户将继续能够使用稳定的 Debian 版本构建其镜像，直到定期支持结束，并且在我们的 CI 中会发生镜像的构建和验证，但在 `main` 分支中不会使用此镜像执行任何单元测试。 ## Airflow 的依赖项管理策略 Airflow 有很多依赖项——直接的和传递的，而且 Airflow 既是库又是应用程序，因此我们对依赖项的策略必须同时包括——应用程序安装的稳定性，但也包括为那些开发 DAG 的用户安装更新版本依赖项的能力。我们开发了一种使用 `constraints` 的方法，以确保可以以可重复的方式安装 airflow，同时我们不限制用户升级大多数依赖项。因此，我们决定默认不对 Airflow 依赖项的版本设置上限，除非我们有充分的理由认为需要设置上限，因为依赖项的重要性以及升级特定依赖项所带来的风险。 我们也会对我们知道会导致问题的依赖项设置上限。 我们的约束机制负责自动查找和升级所有未设置上限的依赖项（前提是所有测试都通过）。如果存在破坏我们测试的依赖项版本，我们的 `main` 构建失败将指示这一点——表明我们应该设置上限或者我们应该修复我们的代码/测试以适应来自这些依赖项的上游更改。 每当我们对此类依赖项设置上限时，我们应该始终注释我们为什么要这样做——即我们应该有充分的理由说明依赖项为何被设置上限。并且我们还应该提及消除限制的条件是什么。 ### Airflow Core 的依赖项策略 这些依赖项在 ``pyproject.toml`` 中维护。 有一些依赖项我们认为足够重要，因此默认对其设置上限，因为已知它们遵循可预测的版本控制方案，而且我们知道这些依赖项的新版本很可能带来破坏性更改。我们承诺定期审查并尝试在依赖项发布时升级到新版本，但这是手动过程。 重要的依赖项是： * `SQLAlchemy`：限制在特定的 MINOR 版本（已知 SQLAlchemy 会移除已弃用的功能并引入破坏性更改，特别是对不同数据库的支持各不相同且变化速度也不同） * `Alembic`：以可预测和高性能的方式处理我们的迁移非常重要。它与 SQLAlchemy 一起开发。我们在 MINOR 版本中使用 Alembic 的经验非常稳定。 * `Flask`：我们使用 Flask 作为 Web UI 和 API 的骨干。我们知道 Flask 的主要版本很可能在这些方面引入破坏性更改，因此将其限制在 MAJOR 版本是有意义的。 * `werkzeug`：已知该库在新版本中会导致问题。它与 Flask 库紧密耦合，我们应该一起更新它们。 * `celery`：Celery 是 Airflow 的关键组件，因为它用于 CeleryExecutor（及类似组件）。Celery [遵循 SemVer](https://docs.celeryq.dev/en/stable/contributing.html?highlight=semver#versions)，因此我们应该将其上限设置为下一个 MAJOR 版本。此外，当我们提升库的上限版本时，我们应该确保更新 Celery Provider 的最低 Airflow 版本。 * `kubernetes`：Kubernetes 是 Airflow 的关键组件，因为它用于 KubernetesExecutor（及类似组件）。Kubernetes Python 库 [遵循 SemVer](https://github.com/kubernetes-client/python#compatibility)，因此我们应该将其上限设置为下一个 MAJOR 版本。此外，当我们提升库的上限版本时，我们应该确保更新 Kubernetes Provider 的最低 Airflow 版本。 ### Airflow Providers 和 extras 中的依赖项策略 Airflow 的主要部分是 Airflow Core，但 Airflow 的强大之处也来自于许多扩展核心功能的 Provider，它们是单独发布的，即使我们（目前）为了方便将它们保存在同一个单体仓库中。您可以在 [Provider 文档](https://airflow.apache.org/docs/apache-airflow-providers/index.html) 中阅读有关 Provider 的更多信息。我们还在 [providers](https://github.com/apache/airflow/blob/main/PROVIDERS.rst) 文档中制定了一套用于维护和发布社区管理的 Provider 以及社区与第三方 Provider 策略的策略。 这些 `extras` 和 `providers` 依赖项在每个 Provider 的 `provider.yaml` 中维护。 默认情况下，我们不应为 Provider 设置依赖项上限，但是每个 Provider 的维护者可能会决定添加额外的限制（并用注释证明其合理性）。 ## 贡献 想帮助构建 Apache Airflow？请查看我们的[贡献者指南](https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)，其中包含如何贡献的全面概述，包括设置说明、编码标准和拉取请求指南。 如果您迫不及待想要贡献并希望尽快开始，请在此处查看[贡献快速入门](https://github.com/apache/airflow/blob/main/contributing-docs/03a_contributors_quick_start_beginners.rst)！ Apache Airflow 的官方 Docker（容器）镜像在 [images](https://github.com/apache/airflow/blob/main/dev/breeze/doc/ci/02_images.md) 中有描述。 ## 投票政策 * 提交需要来自非作者提交者的 +1 票 * 当我们进行 AIP 投票时，PMC 成员和提交者的 `+1s` 均被视为具有约束力的投票。 ## 谁在使用 Apache Airflow？ 我们已知大约有 500 家组织正在使用 Apache Airflow（但实际上可能更多），[在野外](https://github.com/apache/airflow/blob/main/INTHEWILD.md)。 如果您使用 Airflow - 请随时提交 PR 将您的组织添加到列表中。 ## 谁在维护 Apache Airflow？ Airflow 是[社区](https://github.com/apache/airflow/graphs/contributors)的作品，但[核心提交者/维护者](https://people.apache.org/committers-by-project.html#airflow)负责审查和合并 PR 以及引导有关新功能请求的讨论。 如果您想成为维护者，请查看 Apache Airflow [提交者要求](https://github.com/apache/airflow/blob/main/COMMITTERS.rst#guidelines-to-become-an-airflow-committer)。 ## 下一个版本包含什么？ 通常，您会看到一个分配给具有 Airflow 版本的特定里程碑的问题，或者一个合并到主分支的 PR，您可能想知道合并的 PR 将在哪个版本中发布，或者修复的问题将在哪个版本中。答案像往常一样——这取决于各种情况。PR 和问题的答案不同。 为了增加一些背景信息，我们遵循 [Airflow 发布流程](https://airflow.apache.org/docs/apache-airflow/stable/release-process.html)中描述的 [Semver](https://semver.org/) 版本控制方案。更多详细信息在本 README 的[语义化版本控制](#semantic-versioning)章节中有详细说明，但简而言之，我们有 Airflow 的 `MAJOR.MINOR.PATCH` 版本。 * `MAJOR` 版本在发生破坏性更改时递增 * `MINOR` 版本在添加新功能时递增 * `PATCH` 版本在仅包含错误修复和仅文档更改时递增 通常，我们从以 MINOR 版本命名的分支发布 Airflow 的 `MINOR` 版本。例如，`2.7.*` 版本从 `v2-7-stable` 分支发布，`2.8.*` 版本从 `v2-8-stable` 分支发布，依此类推。 1. 在我们发布周期的大部分时间里，当下一个 `MINOR` 的分支尚未创建时，所有合并到 `main` 的 PR（除非它们被还原）都将进入下一个 `MINOR` 版本。例如，如果最后发布的版本是 `2.7.3` 且 `v2-8-stable` 分支尚未创建，则下一个 `MINOR` 版本是 `2.8.0`，所有合并到 main 的 PR 将在 `2.8.0` 中发布。但是，某些 PR（错误修复和仅文档更改）在合并时可以挑选到当前的 `MINOR` 分支并在下一个 `PATCHLEVEL` 版本中发布。例如，如果 `2.8.1` 已经发布并且我们正在开发 `2.9.0dev`，那么用 `2.8.2` 里程碑标记 PR 意味着它将被挑选到 `v2-8-test` 分支并在 `2.8.2rc1` 中发布，并最终在 `2.8.2` 中发布。 2. 当我们准备下一个 `MINOR` 版本时，我们剪切新的 `v2-*-test` 和 `v2-*-stable` 分支并为下一个 `MINOR` 版本准备 `alpha`、`beta` 版本，合并到 main 的 PR 仍将在下一个 `MINOR` 版本中发布，直到 `rc` 版本被剪切。这是因为当下一个 `beta` 和 `rc` 版本准备好时，`v2-*-test` 和 `v2-*-stable` 分支会在 main 之上变基。例如，当我们剪切 `2.10.0beta1` 版本时，在 `2.10.0rc1` 发布之前合并到 main 的任何内容都将进入 2.10.0rc1。 3. 然后，一旦我们为 MINOR 版本准备了第一个 RC 候选版本，我们就停止移动 `v2-*-test` 和 `v2-*-stable` 分支，合并到 main 的 PR 将在下一个 `MINOR` 版本中发布。 但是，某些 PR（错误修复和仅文档更改）在合并时可以挑选到当前的 `MINOR` 分支并在下一个 `PATCHLEVEL` 版本中发布——例如，当 `v2-10-stable` 分支的最后发布版本是 `2.10.0rc1` 时，来自 main 的一些 PR 可以被提交者标记为 `2.10.0` 里程碑，发布经理将尝试将它们挑选到发布分支中。 如果成功，它们将在 `2.10.0rc2` 中发布，随后在 `2.10.0` 中发布。这也适用于后续的 `PATCHLEVEL` 版本。例如，当 `2.10.1` 已经发布时，用 `2.10.2` 里程碑标记 PR 意味着它将被挑选到 `v2-10-stable` 分支并在 `2.10.2rc1` 中发布，并最终在 `2.10.2` 中发布。 关于挑选的最终决定由发布经理做出。 用里程碑标记问题有点不同。维护者通常不会用里程碑标记问题，通常它们只在 PR 中标记。如果链接到问题（并“修复它”）的 PR 按照上述过程合并并在特定版本中发布，问题将自动关闭，不会为问题设置里程碑，您需要检查修复该问题的 PR 以查看它在哪个版本中发布。 但是，有时维护者会用特定的里程碑标记问题，这意味着该问题很重要，是在准备发布时值得查看的候选者。由于这是一个开源项目，基本上所有贡献者都是志愿贡献时间，因此无法保证特定问题会在特定版本中修复。我们不想因为某个问题未修复而推迟发布，因此在这种情况下，发布经理会将此类未修复的问题重新分配给下一个里程碑，以防它们未在当前版本的时间范围内修复。因此，问题的里程碑更多是一种应该查看的意图，而不是将在该版本中修复的承诺。 有关补丁级别发布的更多背景信息和 **FAQ**，请参阅存储库 `dev` 文件夹中的 [What goes into the next release](dev/WHAT_GOES_INTO_THE_NEXT_RELEASE.md) 文档。 ## 我可以在演示文稿中使用 Apache Airflow 的徽标吗？ 可以！请务必遵守 Apache 基金会[商标政策](https://www.apache.org/foundation/marks/#books)和 Apache Airflow [品牌手册](https://cwiki.apache.org/confluence/display/AIRFLOW/Brandbook)。最新的徽标可在[此仓库](https://github.com/apache/airflow/tree/main/airflow-core/docs/img/logos/)和 Apache Software Foundation [网站](https://www.apache.org/logos/about.html)上找到。 ## 链接 - [文档](https://airflow.apache.org/docs/apache-airflow/stable/) - [聊天](https://s.apache.org/airflow-slack) - [社区信息](https://airflow.apache.org/community/) ## 赞助商 Apache Airflow 的 CI 基础设施由以下机构赞助：

标签：Airflow, Apache, CICD, DAG, ETL, JavaCC, Python, 任务调度, 分布式系统, 响应大小分析, 大数据, 子域名突变, 工作流调度, 批处理, 数据工程, 数据科学, 数据管道, 无后门, 监控, 目录扫描, 编排工具, 自动化运维, 请求拦截, 资源验证, 软件工程, 逆向工具