Apache Airflow(또는 간단히 Airflow)는 워크플로를 프로그래밍 방식으로 작성, 예약 및 모니터링하는 플랫폼입니다.
워크플로를 코드로 정의하면 유지 관리, 버전 관리, 테스트 및 협업이 더욱 용이해집니다.
Airflow를 사용하여 작업의 방향성 비순환 그래프(DAG)로 워크플로를 작성합니다. Airflow 스케줄러는 지정된 종속성을 따르는 동안 작업자 배열에서 작업을 실행합니다. 풍부한 명령줄 유틸리티를 사용하면 DAG에 대한 복잡한 수술을 간단하게 수행할 수 있습니다. 풍부한 사용자 인터페이스를 통해 프로덕션에서 실행 중인 파이프라인을 쉽게 시각화하고, 진행 상황을 모니터링하고, 필요할 때 문제를 해결할 수 있습니다.
목차
Airflow는 대부분 정적이고 천천히 변화하는 워크플로에서 가장 잘 작동합니다. DAG 구조가 한 실행에서 다음 실행까지 유사하면 작업 단위와 연속성이 명확해집니다. 다른 유사한 프로젝트로는 Luigi, Oozie 및 Azkaban이 있습니다.
Airflow는 일반적으로 데이터를 처리하는 데 사용되지만 작업은 이상적으로는 멱등성(즉, 작업 결과가 동일하고 대상 시스템에 중복 데이터를 생성하지 않음)이어야 하며 대량의 데이터를 전달해서는 안 된다는 의견이 있습니다. 한 작업에서 다음 작업으로(작업은 Airflow의 XCom 기능을 사용하여 메타데이터를 전달할 수 있음) 대용량, 데이터 집약적 작업의 경우 모범 사례는 해당 유형의 작업을 전문으로 하는 외부 서비스에 위임하는 것입니다.
Airflow는 스트리밍 솔루션은 아니지만 실시간 데이터를 처리하고 일괄적으로 스트림에서 데이터를 가져오는 데 자주 사용됩니다.
Apache Airflow는 다음을 사용하여 테스트되었습니다.
메인 버전(개발자) | 안정 버전(2.10.3) | |
---|---|---|
파이썬 | 3.9, 3.10, 3.11, 3.12 | 3.8, 3.9, 3.10, 3.11, 3.12 |
플랫폼 | AMD64/ARM64(*) | AMD64/ARM64(*) |
쿠버네티스 | 1.28, 1.29, 1.30, 1.31 | 1.27, 1.28, 1.29, 1.30 |
포스트그레SQL | 13, 14, 15, 16, 17 | 12, 13, 14, 15, 16 |
MySQL | 8.0, 8.4, 혁신 | 8.0, 8.4, 혁신 |
SQLite | 3.15.0+ | 3.15.0+ |
* 실험적
참고 : MariaDB는 테스트/권장되지 않습니다.
참고 : SQLite는 Airflow 테스트에 사용됩니다. 프로덕션에서는 사용하지 마세요. 로컬 개발에는 최신 안정 버전의 SQLite를 사용하는 것이 좋습니다.
참고 : Airflow는 현재 POSIX 호환 운영 체제에서 실행될 수 있습니다. 개발을 위해 최신 Linux Distro 및 최신 버전의 macOS에서 정기적으로 테스트됩니다. Windows에서는 WSL2(Linux 2용 Windows 하위 시스템) 또는 Linux 컨테이너를 통해 실행할 수 있습니다. Windows 지원을 추가하는 작업은 #10388을 통해 추적되지만 우선순위가 높지는 않습니다. Linux 기반 배포판은 지원되는 유일한 환경이므로 "프로덕션" 실행 환경으로만 사용해야 합니다. CI 테스트에 사용되고 커뮤니티 관리 DockerHub 이미지에 사용되는 유일한 배포판은 Debian Bookworm
입니다.
Airflow 설치, 시작 또는 보다 완전한 튜토리얼을 살펴보는 데 도움이 필요하면 공식 Airflow 웹 사이트 문서(최신 안정 릴리스)를 방문하세요.
참고: 메인 브랜치(최신 개발 브랜치)에 대한 문서를 찾고 있다면 s.apache.org/airflow-docs에서 찾을 수 있습니다.
AIP(Airflow 개선 제안)에 대한 자세한 내용을 보려면 Airflow Wiki를 방문하세요.
공급자 패키지, Docker 이미지, Helm 차트와 같은 종속 프로젝트에 대한 설명서는 설명서 인덱스에서 찾을 수 있습니다.
우리는 Apache Airflow를 PyPI에 apache-airflow
패키지로 게시합니다. 그러나 Airflow는 라이브러리이자 애플리케이션이기 때문에 설치가 까다로울 수 있습니다. 라이브러리는 일반적으로 종속성을 열어두고 애플리케이션은 일반적으로 이를 고정하지만 둘 중 어느 것도 동시에 수행해서는 안 됩니다. 우리는 사용자가 필요한 경우 다른 버전의 라이브러리를 설치할 수 있도록 종속성을 가능한 한 개방적으로( pyproject.toml
에서) 유지하기로 결정했습니다. 이는 pip install apache-airflow
때때로 작동하지 않거나 사용할 수 없는 Airflow 설치가 발생함을 의미합니다.
그러나 반복 가능한 설치를 위해 고아 constraints-main
및 constraints-2-0
분기에 "작동할 것으로 알려진" 제약 조건 파일 세트를 유지합니다. 우리는 "작동할 것으로 알려진" 제약 조건 파일을 주/부 Python 버전별로 별도로 보관합니다. PyPI에서 Airflow를 설치할 때 제약 조건 파일로 사용할 수 있습니다. URL에 올바른 Airflow 태그/버전/분기 및 Python 버전을 지정해야 합니다.
참고: 현재 공식적으로는
pip
설치만 지원됩니다.
Poetry 또는 pip-tools와 같은 도구를 사용하여 Airflow를 설치할 수 있지만 특히 제약 조건과 요구 사항 관리의 경우 pip
와 동일한 워크플로를 공유하지 않습니다. Poetry
또는 pip-tools
통한 설치는 현재 지원되지 않습니다.
bazel
사용하여 Airflow를 설치할 때 순환 종속성을 초래할 수 있는 알려진 문제가 있습니다. 이러한 문제가 발생하면 pip
로 전환하세요. Bazel
커뮤니티는 this PR <https://github.com/bazelbuild/rules_python/pull/1166>
에서 문제를 해결하기 위해 노력하고 있으므로 최신 버전의 bazel
이 문제를 처리할 수도 있습니다.
이러한 도구를 사용하여 Airflow를 설치하려면 제약 조건 파일을 사용하고 도구에 필요한 적절한 형식과 워크플로로 변환해야 합니다.
pip install ' apache-airflow==2.10.3 '
--constraint " https://raw.githubusercontent.com/apache/airflow/constraints-2.10.3/constraints-3.9.txt "
pip install ' apache-airflow[postgres,google]==2.10.3 '
--constraint " https://raw.githubusercontent.com/apache/airflow/constraints-2.10.3/constraints-3.9.txt "
공급자 패키지 설치에 대한 자세한 내용은 공급자를 확인하세요.
Apache Airflow는 ASF(Apache Software Foundation) 프로젝트이며 공식 소스 코드 릴리스는 다음과 같습니다.
ASF 규칙에 따라 릴리스된 소스 패키지는 사용자가 적절한 플랫폼과 도구에 액세스할 수 있는 경우 릴리스를 빌드하고 테스트하기에 충분해야 합니다.
Airflow를 설치하고 사용하는 다른 방법이 있습니다. 이는 "편리한" 방법입니다. ASF Release Policy
에 명시된 "공식 릴리스"는 아니지만 소프트웨어를 직접 빌드하고 싶지 않은 사용자가 사용할 수 있습니다.
사람들이 Airflow를 설치하는 가장 일반적인 방법의 순서는 다음과 같습니다.
pip
도구를 사용하여 Airflow를 설치하는 PyPI 릴리스docker
도구를 통해 공기 흐름을 설치하고 Kubernetes, Helm Charts, docker-compose
, docker swarm
등에서 사용합니다. 최신 문서에서 이미지 사용, 사용자 정의 및 확장에 대해 자세히 알아보고 내부에 대한 세부 정보를 알아볼 수 있습니다. 이미지 문서에 있습니다.해당 아티팩트는 모두 정식 릴리즈는 아니지만, 공식 릴리즈된 소스를 사용하여 준비한 것입니다. 이러한 아티팩트 중 일부는 "개발" 또는 "사전 릴리스" 아티팩트이며 ASF 정책에 따라 명확하게 표시됩니다.
DAG : 환경의 모든 DAG 개요입니다.
그리드 : 시간에 걸쳐 있는 DAG의 그리드 표현입니다.
그래프 : 특정 실행에 대한 DAG의 종속성과 현재 상태를 시각화합니다.
작업 기간 : 시간이 지남에 따라 다양한 작업에 소요된 총 시간입니다.
간트(Gantt) : DAG의 기간 및 중복.
코드 : DAG의 소스 코드를 보는 빠른 방법입니다.
Airflow 2.0.0부터 출시된 모든 패키지에 대해 엄격한 SemVer 접근 방식을 지원합니다.
다양한 패키지의 버전 관리 세부 사항을 정의하기 위해 우리가 동의한 몇 가지 특정 규칙이 있습니다.
google 4.1.0
및 amazon 3.0.3
공급자는 Airflow 2.1.2
와 함께 설치할 수 있습니다. 공급자와 Airflow 패키지 간의 상호 종속성에 제한이 있는 경우 install_requires
제한 사항으로 공급자에 존재합니다. 우리는 이전에 출시된 모든 Airflow 2 버전과 공급자의 이전 버전과의 호환성을 유지하는 것을 목표로 하지만 때로는 일부 또는 모든 공급자가 최소 Airflow 버전을 지정하게 만드는 주요 변경 사항이 있을 수 있습니다.Apache Airflow 버전 수명 주기:
버전 | 현재 패치/마이너 | 상태 | 첫 번째 릴리스 | 제한된 지원 | EOL/해지됨 |
---|---|---|---|---|---|
2 | 2.10.3 | 지원됨 | 2020년 12월 17일 | 미정 | 미정 |
1.10 | 1.10.15 | 단종 | 2018년 8월 27일 | 2020년 12월 17일 | 2021년 6월 17일 |
1.9 | 1.9.0 | 단종 | 2018년 1월 3일 | 2018년 8월 27일 | 2018년 8월 27일 |
1.8 | 1.8.2 | 단종 | 2017년 3월 19일 | 2018년 1월 3일 | 2018년 1월 3일 |
1.7 | 1.7.1.2 | 단종 | 2016년 3월 28일 | 2017년 3월 19일 | 2017년 3월 19일 |
제한된 지원 버전은 보안 및 중요한 버그 수정으로만 지원됩니다. EOL 버전은 수정이나 지원을 받지 못합니다. 우리는 항상 모든 사용자가 사용 중인 주요 버전에 대해 사용 가능한 최신 부 릴리스를 실행하는 것이 좋습니다. EOL 날짜 이전에 가장 편리한 시간에 최신 Airflow 주요 릴리스로 업그레이드하는 것이 좋습니다 .
Airflow 2.0부터 우리는 Python 및 Kubernetes 지원을 위해 따르는 특정 규칙에 동의했습니다. 이는 Python 개발자 가이드 및 Kubernetes 버전 차이 정책에 잘 요약되어 있는 Python 및 Kubernetes의 공식 출시 일정을 기반으로 합니다.
Python 및 Kubernetes 버전이 EOL에 도달하면 지원을 중단합니다. Kubernetes를 제외하고 두 주요 클라우드 제공업체가 계속 지원을 제공하는 경우 해당 버전은 Airflow에서 계속 지원됩니다. EOL 날짜 직후에 기본 EOL 버전에 대한 지원을 중단하고 Airflow의 첫 번째 새 MINOR(또는 새 MINOR 버전이 없는 경우 MAJOR)를 릴리스할 때 효과적으로 제거됩니다. 예를 들어 Python 3.9의 경우 2023년 6월 27일 직후에 기본 지원이 중단되고 이후 출시된 Airflow의 첫 번째 MAJOR 또는 MINOR 버전에는 지원이 중단됨을 의미합니다.
우리는 Python/Kubernetes의 새 버전이 공식적으로 출시된 후 기본적으로 지원합니다. CI 파이프라인에서 작동하도록 만드는 즉시(주로 Python의 새 버전을 따라잡는 종속성으로 인해 즉시 실행되지 않을 수 있음) 새 이미지를 출시합니다. /작업 CI 설정을 기반으로 하는 Airflow의 지원입니다.
이 정책은 상황에 따라 지원을 더 일찍 종료할 수 있는 상황이 있을 수 있다는 것을 의미하는 최선의 노력입니다.
Airflow 커뮤니티는 Apache Airflow 릴리스를 게시할 때마다 게시되는 편리하게 패키지된 컨테이너 이미지를 제공합니다. 해당 이미지에는 다음이 포함됩니다.
기본 OS 이미지의 버전은 Debian의 안정 버전입니다. Airflow는 모든 Airflow 종속 항목이 빌드를 지원하는 즉시 현재 활성화된 모든 안정 버전 사용을 지원하고 OS 버전 빌드 및 테스트를 위한 CI 파이프라인을 설정합니다. 이전 안정 버전 OS의 정기 지원이 종료되기 약 6개월 전, 에어플로우는 지원되는 최신 버전의 OS를 사용하도록 출시된 이미지를 전환합니다.
예를 들어 Debian Bullseye
에서 Debian Bookworm
으로의 전환은 2023년 10월 2.8.0 릴리스 이전에 구현되었으며 Debian Bookworm
Airflow 2.10.0부터 지원되는 유일한 옵션입니다.
사용자는 정규 지원이 종료될 때까지 안정적인 Debian 릴리스를 사용하여 이미지를 계속 빌드할 수 있으며 CI에서 이미지 빌드 및 확인이 이루어지지만 main
브랜치에서는 이 이미지를 사용하여 단위 테스트가 실행되지 않았습니다.
Airflow에는 많은 종속성이 있습니다(직접 및 전이적). 또한 Airflow는 라이브러리와 애플리케이션 모두이므로 종속성에 대한 정책에는 애플리케이션 설치의 안정성뿐만 아니라 개발하는 사용자를 위해 최신 버전의 종속성을 설치하는 기능도 포함되어야 합니다. DAG. 우리는 공기 흐름이 반복 가능한 방식으로 설치될 수 있도록 constraints
사용하는 동시에 사용자가 대부분의 종속성을 업그레이드하도록 제한하지 않는 접근 방식을 개발했습니다. 결과적으로 우리는 종속성의 중요성과 특정 종속성을 업그레이드하는 데 수반되는 위험으로 인해 상한이 필요하다고 믿을 타당한 이유가 없는 한 기본적으로 Airflow 종속성의 상한 버전을 사용하지 않기로 결정했습니다. 또한 문제를 일으키는 것으로 알려진 종속성의 상한선도 지정했습니다.
우리의 제약 메커니즘은 상한이 아닌 모든 종속성을 자동으로 찾고 업그레이드하는 데 신경을 씁니다(모든 테스트가 통과하는 경우). main
빌드 실패는 테스트를 중단시키는 종속성 버전이 있는 경우를 나타냅니다. 즉, 이를 상위 바인딩해야 하거나 해당 종속성의 업스트림 변경 사항을 설명하기 위해 코드/테스트를 수정해야 함을 나타냅니다.
그러한 종속성을 상한으로 설정할 때마다 항상 왜 그렇게 하는지 설명해야 합니다. 즉, 종속성이 상한으로 설정된 타당한 이유가 있어야 합니다. 그리고 바인딩을 제거하는 조건이 무엇인지도 언급해야 합니다.
이러한 종속성은 pyproject.toml
에서 유지됩니다.
예측 가능한 버전 관리 체계를 따르는 것으로 알려져 있기 때문에 기본적으로 상한선을 지정할 만큼 중요하다고 판단한 종속성은 거의 없으며 이러한 새 버전이 획기적인 변경을 가져올 가능성이 매우 높다는 것을 알고 있습니다. 우리는 정기적으로 최신 버전의 종속성을 검토하고 업그레이드하려고 노력하고 있지만 이는 수동 프로세스입니다.
중요한 종속성은 다음과 같습니다.
SQLAlchemy
: 특정 MINOR 버전에 대한 상한(SQLAlchemy는 더 이상 사용되지 않는 사항을 제거하고 특히 다양한 데이터베이스에 대한 지원이 다양하고 다양한 속도로 변경되는 주요 변경 사항을 도입하는 것으로 알려져 있습니다)Alembic
: 예측 가능하고 효율적인 방식으로 마이그레이션을 처리하는 것이 중요합니다. SQLAlchemy와 함께 개발되었습니다. Alembic에 대한 우리의 경험에 따르면 MINOR 버전에서는 매우 안정적입니다.Flask
: 우리는 Flask를 웹 UI와 API의 백본으로 사용하고 있습니다. 우리는 Flask의 주요 버전이 여러 버전에 걸쳐 획기적인 변경 사항을 도입할 가능성이 매우 높다는 것을 알고 있으므로 이를 주요 버전으로 제한하는 것이 합리적입니다.werkzeug
: 라이브러리는 새 버전에서 문제를 일으키는 것으로 알려져 있습니다. Flask 라이브러리와 긴밀하게 결합되어 있으므로 함께 업데이트해야 합니다.celery
: Celery는 CeleryExecutor(및 유사)에 사용되는 Airflow의 중요한 구성 요소입니다. Celery는 SemVer를 따르므로 다음 MAJOR 버전으로 상한을 지정해야 합니다. 또한 라이브러리의 상위 버전을 올릴 때 Celery Provider 최소 Airflow 버전이 업데이트되었는지 확인해야 합니다.kubernetes
: Kubernetes는 KubernetesExecutor(및 유사)에 사용되므로 Airflow의 중요한 구성 요소입니다. Kubernetes Python 라이브러리는 SemVer를 따르므로 다음 MAJOR 버전으로 상한을 설정해야 합니다. 또한 라이브러리의 상위 버전을 올릴 때 Kubernetes Provider 최소 Airflow 버전이 업데이트되었는지 확인해야 합니다.Airflow의 주요 부분은 Airflow Core이지만, Airflow의 강력한 기능은 핵심 기능을 확장하고 별도로 출시되는 여러 제공자로부터 나옵니다. 비록 우리가 편의를 위해 (현재) 동일한 단일 저장소에 유지하더라도 말이죠. 공급자 문서에서 공급자에 대한 자세한 내용을 읽을 수 있습니다. 또한 커뮤니티에서 관리하는 공급자를 유지 및 해제하기 위해 구현된 일련의 정책과 공급자 문서의 커뮤니티 대 제3자 공급자에 대한 접근 방식도 있습니다.
이러한 extras
과 providers
종속성은 각 공급자의 provider.yaml
에서 유지 관리됩니다.
기본적으로 공급자에 대한 상한 종속성을 설정해서는 안 되지만, 각 공급자의 유지 관리 담당자는 추가 제한을 추가하기로 결정할 수도 있습니다(설명으로 이를 정당화).
Apache Airflow 구축을 돕고 싶으십니까? 설정 지침, 코딩 표준, 끌어오기 요청 지침을 포함하여 기여 방법에 대한 포괄적인 개요를 보려면 기여자 가이드를 확인하세요.
기여하고 싶고 최대한 빨리 시작하고 싶다면 여기에서 기여 빠른 시작을 확인하세요!
Apache Airflow의 공식 Docker(컨테이너) 이미지는 이미지에 설명되어 있습니다.
+1s
모두 구속력 있는 투표로 간주됩니다. 우리는 실제로 Apache Airflow를 사용하고 있는 약 500개 조직을 알고 있습니다(하지만 그보다 더 많을 가능성이 높습니다).
Airflow를 사용하는 경우 자유롭게 PR을 작성하여 조직을 목록에 추가하세요.
Airflow는 커뮤니티의 작업이지만 핵심 커미터/유지관리자는 PR을 검토 및 병합하고 새로운 기능 요청에 대한 대화를 조정할 책임이 있습니다. 관리자가 되고 싶다면 Apache Airflow 커미터 요구 사항을 검토하세요.
종종 Airflow 버전의 특정 마일스톤에 할당된 문제나 메인 브랜치에 병합된 PR을 볼 수 있으며 병합된 PR이 어느 릴리스에서 릴리스될지 또는 해결된 문제가 어느 릴리스에서 릴리스될지 궁금할 수 있습니다. in. 이에 대한 대답은 평소와 같습니다. 다양한 시나리오에 따라 다릅니다. PR과 이슈에 대한 대답은 다릅니다.
약간의 컨텍스트를 추가하기 위해 Airflow 릴리스 프로세스에 설명된 대로 Semver 버전 관리 체계를 따르고 있습니다. 자세한 내용은 이 README의 의미 체계 버전 관리 장에 자세히 설명되어 있지만 간단히 말해서 Airflow의 MAJOR.MINOR.PATCH
버전이 있습니다.
MAJOR
버전이 증가됩니다.MINOR
버전이 증가합니다.PATCH
버전이 증가합니다. 일반적으로 우리는 MINOR 버전의 이름을 딴 분기에서 Airflow의 MINOR
버전을 출시합니다. 예를 들어 2.7.*
릴리스는 v2-7-stable
분기에서 릴리스되고, 2.8.*
릴리스는 v2-8-stable
분기에서 릴리스됩니다.
릴리스 주기의 대부분의 경우 다음 MINOR
브랜치를 위한 브랜치가 아직 생성되지 않은 경우 main
에 병합된 모든 PR(되돌려지지 않는 한)은 다음 MINOR
릴리스로 향하게 됩니다. 예를 들어 마지막 릴리스가 2.7.3
이고 v2-8-stable
분기가 아직 생성되지 않은 경우 다음 MINOR
릴리스는 2.8.0
이고 기본에 병합된 모든 PR은 2.8.0
에서 릴리스됩니다. 그러나 병합 시 일부 PR(버그 수정 및 문서 전용 변경 사항)은 현재 MINOR
분기로 선택되어 다음 PATCHLEVEL
릴리스에서 릴리스될 수 있습니다. 예를 들어, 2.8.1
이 이미 릴리스되었고 2.9.0dev
에서 작업 중인 경우 2.8.2
마일스톤으로 PR을 표시하면 해당 PR이 v2-8-test
브랜치로 선택되어 2.8.2rc1
에서 릴리스된다는 의미입니다. 그리고 결국 2.8.2
에 있습니다.
다음 MINOR
릴리스를 준비할 때 새로운 v2-*-test
및 v2-*-stable
브랜치를 잘라내고 다음 MINOR
버전을 위한 alpha
, beta
릴리스를 준비합니다. 메인에 병합된 PR은 다음 MINOR
릴리스에서도 계속 릴리스됩니다. rc
버전이 잘릴 때까지. 이는 다음 beta
및 rc
릴리스가 준비될 때 v2-*-test
및 v2-*-stable
분기가 기본 분기를 기반으로 리베이스되기 때문에 발생합니다. 예를 들어, 2.10.0beta1
버전을 자르면 2.10.0rc1
이 출시되기 전에 기본 버전으로 병합된 모든 항목이 2.10.0rc1로 이동됩니다.
그런 다음 MINOR 릴리스에 대한 첫 번째 RC 후보를 준비하면 v2-*-test
및 v2-*-stable
분기 이동을 중지하고 기본에 병합된 PR이 다음 MINOR
릴리스에서 릴리스됩니다. 그러나 병합 시 일부 PR(버그 수정 및 문서 전용 변경 사항)은 현재 MINOR
분기로 선별되어 다음 PATCHLEVEL
릴리스에서 릴리스될 수 있습니다. 예를 들어 v2-10-stable
분기에서 마지막으로 릴리스된 버전이 2.10.0rc1
인 경우 2.10.0rc1
, 메인 PR의 일부는 커미터에 의해 2.10.0
마일스톤으로 표시될 수 있으며, 릴리스 관리자는 이를 릴리스 브랜치로 선별하려고 시도합니다. 성공하면 2.10.0rc2
와 이후 2.10.0
에서 릴리스됩니다. 이는 후속 PATCHLEVEL
버전에도 적용됩니다. 예를 들어 2.10.1
이 이미 릴리스된 경우 2.10.2
마일스톤으로 PR을 표시하면 해당 PR이 v2-10-stable
브랜치로 선별되어 2.10.2rc1
에서 릴리스되고 결국 2.10.2
에서 릴리스된다는 의미입니다.
체리 피킹에 대한 최종 결정은 릴리스 관리자가 내립니다.
마일스톤으로 문제를 표시하는 것은 약간 다릅니다. 유지관리자는 일반적으로 문제에 마일스톤을 표시하지 않으며 일반적으로 PR에만 표시됩니다. 문제에 연결된 PR(및 "수정")이 위에서 설명한 프로세스에 따라 특정 버전으로 병합 및 릴리스되면 문제가 자동으로 닫히고 해당 문제에 대한 마일스톤이 설정되지 않으므로 PR을 확인해야 합니다. 어떤 버전으로 출시되었는지 확인하기 위해 문제를 해결했습니다.
그러나 관리자가 이슈를 특정 마일스톤으로 표시하는 경우도 있는데, 이는 릴리스가 준비될 때 살펴볼 후보가 되기 위해 이슈가 중요하다는 것을 의미합니다. 이는 기본적으로 모든 기여자가 자원 봉사하는 오픈 소스 프로젝트이므로 특정 버전에서 특정 문제가 해결될 것이라는 보장은 없습니다. 일부 문제가 수정되지 않았기 때문에 릴리스를 보류하고 싶지 않으므로 이러한 경우 릴리스 관리자는 수정되지 않은 문제가 현재 릴리스에 맞춰 수정되지 않은 경우 다음 마일스톤에 다시 할당합니다. 따라서 문제의 마일스톤은 버전에서 수정될 것이라는 약속보다는 살펴봐야 한다는 의도에 가깝습니다.
패치 수준 릴리스에 대한 자세한 내용과 FAQ는 저장소의 dev
폴더에 있는 다음 릴리스에 들어갈 내용 문서에서 찾을 수 있습니다.
예! Apache Foundation 상표 정책과 Apache Airflow 브랜드북을 준수하십시오. 최신 로고는 이 저장소와 Apache Software Foundation 웹 사이트에서 찾을 수 있습니다.
Apache Airflow용 CI 인프라는 다음의 후원을 받았습니다.