airflow
Apache Airflow 2.10.3
Apache Airflow (oder einfach Airflow) ist eine Plattform zum programmgesteuerten Erstellen, Planen und Überwachen von Arbeitsabläufen.
Wenn Workflows als Code definiert werden, werden sie besser wartbar, versionierbar, testbar und kollaborativer.
Verwenden Sie Airflow, um Workflows als gerichtete azyklische Diagramme (DAGs) von Aufgaben zu erstellen. Der Airflow-Planer führt Ihre Aufgaben für eine Reihe von Workern aus und folgt dabei den angegebenen Abhängigkeiten. Umfangreiche Befehlszeilen-Dienstprogramme machen die Durchführung komplexer Operationen an DAGs zum Kinderspiel. Die umfangreiche Benutzeroberfläche erleichtert die Visualisierung der in der Produktion laufenden Pipelines, die Überwachung des Fortschritts und die Fehlerbehebung bei Bedarf.
Inhaltsverzeichnis
Airflow funktioniert am besten mit Arbeitsabläufen, die größtenteils statisch sind und sich langsam ändern. Wenn die DAG-Struktur von einem Lauf zum nächsten ähnlich ist, verdeutlicht dies die Arbeitseinheit und die Kontinuität. Weitere ähnliche Projekte sind Luigi, Oozie und Askaban.
Airflow wird häufig zum Verarbeiten von Daten verwendet, ist jedoch der Meinung, dass Aufgaben idealerweise idempotent sein sollten (d. h. die Ergebnisse der Aufgabe sind gleich und es werden keine doppelten Daten in einem Zielsystem erstellt) und keine großen Datenmengen weitergegeben werden sollten von einer Aufgabe zur nächsten (obwohl Aufgaben mithilfe der XCom-Funktion von Airflow Metadaten weitergeben können). Bei umfangreichen, datenintensiven Aufgaben besteht eine bewährte Vorgehensweise darin, externe Dienste zu beauftragen, die auf diese Art von Arbeit spezialisiert sind.
Airflow ist keine Streaming-Lösung, wird jedoch häufig zur Verarbeitung von Echtzeitdaten verwendet, indem Daten stapelweise aus Streams abgerufen werden.
Apache Airflow wurde getestet mit:
| Hauptversion (Entwickler) | Stabile Version (2.10.3) | |
|---|---|---|
| Python | 3.9, 3.10, 3.11, 3.12 | 3.8, 3.9, 3.10, 3.11, 3.12 |
| Plattform | AMD64/ARM64(*) | AMD64/ARM64(*) |
| Kubernetes | 1,28, 1,29, 1,30, 1,31 | 1,27, 1,28, 1,29, 1,30 |
| PostgreSQL | 13, 14, 15, 16, 17 | 12, 13, 14, 15, 16 |
| MySQL | 8.0, 8.4, Innovation | 8.0, 8.4, Innovation |
| SQLite | 3.15.0+ | 3.15.0+ |
* Experimentell
Hinweis : MariaDB ist nicht getestet/empfohlen.
Hinweis : SQLite wird in Airflow-Tests verwendet. Verwenden Sie es nicht in der Produktion. Wir empfehlen die Verwendung der neuesten stabilen Version von SQLite für die lokale Entwicklung.
Hinweis : Airflow kann derzeit auf POSIX-kompatiblen Betriebssystemen ausgeführt werden. Für die Entwicklung wird es regelmäßig auf relativ modernen Linux-Distributionen und aktuellen Versionen von macOS getestet. Unter Windows können Sie es über WSL2 (Windows-Subsystem für Linux 2) oder über Linux-Container ausführen. Die Arbeit zum Hinzufügen der Windows-Unterstützung wird über #10388 verfolgt, hat jedoch keine hohe Priorität. Sie sollten nur Linux-basierte Distributionen als „Produktions“-Ausführungsumgebung verwenden, da dies die einzige unterstützte Umgebung ist. Die einzige Distribution, die in unseren CI-Tests und im von der Community verwalteten DockerHub-Image verwendet wird, ist Debian Bookworm .
Besuchen Sie die offizielle Airflow-Website-Dokumentation (neueste stabile Version), um Hilfe bei der Installation von Airflow, den ersten Schritten oder einem ausführlicheren Tutorial zu erhalten.
Hinweis: Wenn Sie nach Dokumentation für den Hauptzweig (neuesten Entwicklungszweig) suchen, finden Sie diese unter s.apache.org/airflow-docs.
Weitere Informationen zu Airflow Improvement Proposals (AIPs) finden Sie im Airflow Wiki.
Dokumentation für abhängige Projekte wie Anbieterpakete, Docker-Image, Helm Chart finden Sie im Dokumentationsindex.
Wir veröffentlichen Apache Airflow als apache-airflow Paket in PyPI. Die Installation kann jedoch manchmal schwierig sein, da Airflow sowohl eine Bibliothek als auch eine Anwendung ist. Bibliotheken halten ihre Abhängigkeiten normalerweise offen und Anwendungen heften sie normalerweise an, aber wir sollten keines von beiden und beides gleichzeitig tun. Wir haben uns entschieden, unsere Abhängigkeiten so offen wie möglich zu halten (in pyproject.toml ), damit Benutzer bei Bedarf verschiedene Versionen von Bibliotheken installieren können. Dies bedeutet, dass pip install apache-airflow von Zeit zu Zeit nicht funktioniert oder zu einer unbrauchbaren Airflow-Installation führt.
Um eine wiederholbare Installation zu gewährleisten, behalten wir jedoch eine Reihe von „bekanntermaßen funktionierenden“ Einschränkungsdateien in den verwaisten Zweigen constraints-main und constraints-2-0 bei. Wir bewahren diese „bekanntermaßen funktionierenden“ Einschränkungsdateien getrennt nach Haupt-/Nebenversion von Python auf. Sie können sie als Einschränkungsdateien verwenden, wenn Sie Airflow von PyPI installieren. Beachten Sie, dass Sie in der URL die korrekten Airflow-Tags/Versionen/Branch- und Python-Versionen angeben müssen.
Hinweis: Derzeit wird nur
pip-Installation offiziell unterstützt.
Es ist zwar möglich, Airflow mit Tools wie Poetry oder pip-tools zu installieren, sie nutzen jedoch nicht denselben Workflow wie pip – insbesondere, wenn es um das Management von Einschränkungen und Anforderungen geht. Die Installation über Poetry oder pip-tools wird derzeit nicht unterstützt.
Es gibt bekannte Probleme mit bazel , die bei der Installation von Airflow zu zirkulären Abhängigkeiten führen können. Bitte wechseln Sie zu pip wenn Sie auf solche Probleme stoßen. Bazel Community arbeitet an der Behebung des Problems in this PR <https://github.com/bazelbuild/rules_python/pull/1166> _, daher kann es sein, dass neuere Versionen von bazel das Problem lösen.
Wenn Sie Airflow mit diesen Tools installieren möchten, sollten Sie die Einschränkungsdateien verwenden und sie in das entsprechende Format und den entsprechenden Workflow konvertieren, den Ihr Tool erfordert.
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 "Informationen zur Installation von Anbieterpaketen finden Sie bei den Anbietern.
Apache Airflow ist ein Projekt der Apache Software Foundation (ASF) und unsere offiziellen Quellcode-Veröffentlichungen:
Gemäß den ASF-Regeln müssen die veröffentlichten Quellpakete ausreichen, damit ein Benutzer die Version erstellen und testen kann, vorausgesetzt, er hat Zugriff auf die entsprechende Plattform und die entsprechenden Tools.
Es gibt andere Möglichkeiten, Airflow zu installieren und zu verwenden. Dies sind „bequeme“ Methoden – es handelt sich nicht um „offizielle Veröffentlichungen“, wie in der ASF Release Policy angegeben, aber sie können von Benutzern verwendet werden, die die Software nicht selbst erstellen möchten.
Das sind – in der Reihenfolge der häufigsten Arten, wie Menschen Airflow installieren:
pip Tooldocker Tool, deren Verwendung in Kubernetes, Helm-Charts, docker-compose , docker swarm usw. Sie können mehr über die Verwendung, Anpassung und Erweiterung der Images in den neuesten Dokumenten lesen und Details zu den Interna erfahren im Bilddokument.Bei all diesen Artefakten handelt es sich nicht um offizielle Veröffentlichungen, sie wurden jedoch anhand offiziell veröffentlichter Quellen erstellt. Bei einigen dieser Artefakte handelt es sich um „Entwicklungs“- oder „Vorabversionsartefakte“ und sie sind gemäß der ASF-Richtlinie deutlich als solche gekennzeichnet.
DAGs : Übersicht aller DAGs in Ihrer Umgebung.
Raster : Rasterdarstellung einer DAG, die sich über die Zeit erstreckt.
Diagramm : Visualisierung der Abhängigkeiten einer DAG und ihres aktuellen Status für einen bestimmten Lauf.
Aufgabendauer : Gesamtzeit, die im Laufe der Zeit für verschiedene Aufgaben aufgewendet wurde.
Gantt : Dauer und Überlappung eines DAG.
Code : Schnelle Möglichkeit, den Quellcode einer DAG anzuzeigen.
Ab Airflow 2.0.0 unterstützen wir einen strikten SemVer-Ansatz für alle veröffentlichten Pakete.
Wir haben uns auf einige spezifische Regeln geeinigt, die die Details der Versionierung der verschiedenen Pakete definieren:
google 4.1.0 und amazon 3.0.3 problemlos mit Airflow 2.1.2 installiert werden. Wenn es Grenzen für gegenseitige Abhängigkeiten zwischen Anbietern und Airflow-Paketen gibt, sind diese in den Anbietern als install_requires Einschränkungen vorhanden. Unser Ziel ist es, die Abwärtskompatibilität der Anbieter mit allen zuvor veröffentlichten Airflow 2-Versionen aufrechtzuerhalten. Allerdings kommt es manchmal zu bahnbrechenden Änderungen, die dazu führen können, dass einige oder alle Anbieter eine Mindestversion von Airflow angeben.Lebenszyklus der Apache Airflow-Version:
| Version | Aktueller Patch/Minor | Zustand | Erste Veröffentlichung | Eingeschränkter Support | EOL/Beendet |
|---|---|---|---|---|---|
| 2 | 2.10.3 | Unterstützt | 17. Dezember 2020 | Noch offen | Noch offen |
| 1.10 | 1.10.15 | EOL | 27. August 2018 | 17. Dezember 2020 | 17. Juni 2021 |
| 1.9 | 1.9.0 | EOL | 3. Januar 2018 | 27. August 2018 | 27. August 2018 |
| 1.8 | 1.8.2 | EOL | 19. März 2017 | 3. Januar 2018 | 3. Januar 2018 |
| 1.7 | 1.7.1.2 | EOL | 28. März 2016 | 19. März 2017 | 19. März 2017 |
Versionen mit eingeschränktem Support werden nur mit Sicherheit und kritischer Fehlerbehebung unterstützt. EOL-Versionen erhalten weder Korrekturen noch Support. Wir empfehlen allen Benutzern immer, die neueste verfügbare Nebenversion für die jeweils verwendete Hauptversion auszuführen. Wir empfehlen dringend, zum frühestmöglichen Zeitpunkt und vor dem EOL-Datum ein Upgrade auf die neueste Airflow-Hauptversion durchzuführen.
Ab Airflow 2.0 haben wir bestimmten Regeln zugestimmt, die wir für die Python- und Kubernetes-Unterstützung befolgen. Sie basieren auf dem offiziellen Veröffentlichungsplan von Python und Kubernetes, der im Python-Entwicklerhandbuch und in der Versionsabweichungsrichtlinie von Kubernetes gut zusammengefasst ist.
Wir stellen die Unterstützung für Python- und Kubernetes-Versionen ein, wenn sie EOL erreichen. Mit Ausnahme von Kubernetes bleibt eine Version von Airflow unterstützt, wenn zwei große Cloud-Anbieter weiterhin Unterstützung dafür bereitstellen. Wir stellen die Unterstützung für diese EOL-Versionen in der Hauptversion direkt nach dem EOL-Datum ein und sie wird effektiv entfernt, wenn wir die erste neue MINOR-Version (oder MAJOR, wenn es keine neue MINOR-Version gibt) von Airflow veröffentlichen. Für Python 3.9 bedeutet dies beispielsweise, dass wir die Hauptunterstützung direkt nach dem 27.06.2023 einstellen und die erste MAJOR- oder MINOR-Version von Airflow, die danach veröffentlicht wird, nicht über diese verfügen wird.
Wir unterstützen hauptsächlich eine neue Version von Python/Kubernetes, nachdem sie offiziell veröffentlicht wurde. Sobald wir sie in unserer CI-Pipeline zum Laufen bringen (was aufgrund von Abhängigkeiten, die meist mit neuen Python-Versionen einhergehen, möglicherweise nicht sofort erfolgt), veröffentlichen wir neue Images /support in Airflow basierend auf dem funktionierenden CI-Setup.
Bei dieser Richtlinie handelt es sich um eine Best-Effort-Richtlinie, was bedeutet, dass es Situationen geben kann, in denen wir den Support früher beenden, wenn die Umstände dies erfordern.
Die Airflow-Community stellt bequem verpackte Container-Images bereit, die immer dann veröffentlicht werden, wenn wir eine Apache Airflow-Version veröffentlichen. Diese Bilder enthalten:
Die Version des Basis-Betriebssystem-Images ist die stabile Version von Debian. Airflow unterstützt die Verwendung aller derzeit aktiven stabilen Versionen – sobald alle Airflow-Abhängigkeiten das Erstellen unterstützen und wir die CI-Pipeline zum Erstellen und Testen der Betriebssystemversion einrichten. Ungefähr 6 Monate vor dem Ende des regulären Supports einer früheren stabilen Version des Betriebssystems stellt Airflow die veröffentlichten Images auf die neueste unterstützte Version des Betriebssystems um.
Beispielsweise wurde der Wechsel von Debian Bullseye zu Debian Bookworm vor der Veröffentlichung von 2.8.0 im Oktober 2023 implementiert und Debian Bookworm wird ab Airflow 2.10.0 die einzige unterstützte Option sein.
Benutzer können ihre Images bis zum Ende des regulären Supports weiterhin mit stabilen Debian-Versionen erstellen und die Erstellung und Überprüfung der Images erfolgt in unserem CI, es wurden jedoch keine Unit-Tests mit diesem Image im main durchgeführt.
Airflow hat viele Abhängigkeiten – direkt und transitiv, außerdem ist Airflow beides – Bibliothek und Anwendung. Daher müssen unsere Richtlinien für Abhängigkeiten beides umfassen – Stabilität der Installation der Anwendung, aber auch die Möglichkeit, neuere Versionen von Abhängigkeiten für diejenigen Benutzer zu installieren, die entwickeln DAGs. Wir haben den Ansatz entwickelt, bei dem constraints verwendet werden, um sicherzustellen, dass der Luftstrom wiederholbar installiert werden kann, während wir unsere Benutzer nicht darauf beschränken, die meisten Abhängigkeiten zu aktualisieren. Aus diesem Grund haben wir uns entschieden, die Version der Airflow-Abhängigkeiten nicht standardmäßig auf eine Obergrenze zu beschränken, es sei denn, wir haben gute Gründe zu der Annahme, dass eine Obergrenze für die Version aufgrund der Bedeutung der Abhängigkeit und des Risikos, das mit der Aktualisierung einer bestimmten Abhängigkeit verbunden ist, erforderlich ist. Wir begrenzen auch die Abhängigkeiten, von denen wir wissen, dass sie Probleme verursachen, nach oben.
Unser Einschränkungsmechanismus kümmert sich darum, alle Abhängigkeiten außerhalb der Obergrenze automatisch zu finden und zu aktualisieren (vorausgesetzt, dass alle Tests erfolgreich sind). Unsere main -Build-Fehler zeigen an, ob es Versionen von Abhängigkeiten gibt, die unsere Tests unterbrechen – was bedeutet, dass wir sie entweder nach oben binden oder unseren Code/Tests korrigieren sollten, um die Upstream-Änderungen dieser Abhängigkeiten zu berücksichtigen.
Wann immer wir eine solche Abhängigkeit auf eine Obergrenze setzen, sollten wir immer kommentieren, warum wir das tun – das heißt, wir sollten einen guten Grund haben, warum die Abhängigkeit eine Obergrenze darstellt. Und wir sollten auch erwähnen, unter welchen Bedingungen die Bindung entfernt werden kann.
Diese Abhängigkeiten werden in pyproject.toml verwaltet.
Es gibt nur wenige Abhängigkeiten, die unserer Meinung nach wichtig genug sind, um sie standardmäßig nach oben zu begrenzen, da sie bekanntermaßen einem vorhersehbaren Versionierungsschema folgen und wir wissen, dass neue Versionen davon sehr wahrscheinlich wichtige Änderungen mit sich bringen. Wir verpflichten uns, die Abhängigkeiten regelmäßig zu überprüfen und zu versuchen, auf die neueren Versionen zu aktualisieren, sobald diese veröffentlicht werden. Dies ist jedoch ein manueller Vorgang.
Die wichtigen Abhängigkeiten sind:
SQLAlchemy : Obergrenze an bestimmte MINOR-Version (Es ist bekannt, dass SQLAlchemy veraltete Versionen entfernt und bahnbrechende Änderungen einführt, insbesondere da die Unterstützung für verschiedene Datenbanken unterschiedlich ist und sich mit unterschiedlicher Geschwindigkeit ändert.)Alembic : Es ist wichtig, unsere Migrationen vorhersehbar und effizient abzuwickeln. Es wurde zusammen mit SQLAlchemy entwickelt. Unsere Erfahrung mit Alembic ist, dass es in der MINOR-Version sehr stabil istFlask : Wir verwenden Flask als Rückgrat unserer Web-Benutzeroberfläche und API. Wir wissen, dass die Hauptversion von Flask sehr wahrscheinlich bahnbrechende Änderungen mit sich bringt, daher ist es sinnvoll, sie auf die Hauptversion zu beschränkenwerkzeug : Es ist bekannt, dass die Bibliothek in neuen Versionen Probleme verursacht. Es ist eng mit den Flask-Bibliotheken verknüpft und wir sollten sie gemeinsam aktualisierencelery : Sellerie ist ein entscheidender Bestandteil von Airflow, da er für CeleryExecutor (und ähnliches) verwendet wird. Celery folgt SemVer, daher sollten wir es auf die nächste MAJOR-Version beschränken. Wenn wir die obere Version der Bibliothek erweitern, sollten wir außerdem sicherstellen, dass die Airflow-Mindestversion von Celery Provider aktualisiert wird.kubernetes : Kubernetes ist eine entscheidende Komponente von Airflow, da es für den KubernetesExecutor (und ähnliches) verwendet wird. Die Kubernetes-Python-Bibliothek folgt SemVer, daher sollten wir sie auf die nächste MAJOR-Version beschränken. Wenn wir die höhere Version der Bibliothek aktualisieren, sollten wir außerdem sicherstellen, dass die Airflow-Mindestversion des Kubernetes-Anbieters aktualisiert wird.Der Hauptteil des Airflow ist der Airflow Core, aber die Leistung von Airflow kommt auch von einer Reihe von Anbietern, die die Kernfunktionalität erweitern und separat veröffentlicht werden, auch wenn wir sie der Einfachheit halber (vorerst) im selben Monorepo belassen. Weitere Informationen zu den Anbietern finden Sie in der Anbieterdokumentation. Wir haben außerdem eine Reihe von Richtlinien für die Wartung und Freigabe von von der Community verwalteten Anbietern sowie den Ansatz für Community- und Drittanbieter-Anbieter im Anbieterdokument implementiert.
Diese extras und providers werden in provider.yaml jedes Anbieters verwaltet.
Standardmäßig sollten wir die Abhängigkeiten für Anbieter nicht nach oben beschränken, der Betreuer jedes Anbieters kann jedoch beschließen, zusätzliche Grenzwerte hinzuzufügen (und diese mit Kommentaren zu begründen).
Möchten Sie beim Aufbau von Apache Airflow helfen? Sehen Sie sich unseren Leitfaden für Mitwirkende an, um einen umfassenden Überblick darüber zu erhalten, wie Sie Beiträge leisten können, einschließlich Einrichtungsanweisungen, Codierungsstandards und Pull-Request-Richtlinien.
Wenn Sie es kaum erwarten können, einen Beitrag zu leisten, und so schnell wie möglich loslegen möchten, sehen Sie sich hier den Beitrags-Schnellstart an!
Offizielle Docker-(Container-)Images für Apache Airflow werden in Bildern beschrieben.
+1s von PMC-Mitgliedern und Committern als verbindliche Abstimmung. Wir wissen von rund 500 Organisationen, die Apache Airflow im Umlauf nutzen (aber es gibt wahrscheinlich noch viel mehr).
Wenn Sie Airflow verwenden, können Sie gerne eine PR erstellen, um Ihre Organisation zur Liste hinzuzufügen.
Airflow ist die Arbeit der Community, aber die Hauptcommitter/Betreuer sind für die Überprüfung und Zusammenführung von PRs sowie die Steuerung von Gesprächen rund um neue Funktionswünsche verantwortlich. Wenn Sie Betreuer werden möchten, lesen Sie bitte die Apache Airflow-Committer-Anforderungen.
Oft sehen Sie ein Problem, das einem bestimmten Meilenstein der Airflow-Version zugeordnet ist, oder eine PR, die mit dem Hauptzweig zusammengeführt wird, und Sie fragen sich möglicherweise, in welcher Version die zusammengeführten PRs veröffentlicht werden oder welche Version die behobenen Probleme sein werden in. Die Antwort darauf ist wie immer – sie hängt von verschiedenen Szenarien ab. Die Antwort ist für PRs und Issues unterschiedlich.
Um ein wenig Kontext hinzuzufügen, folgen wir dem Semver-Versionierungsschema, wie im Airflow-Veröffentlichungsprozess beschrieben. Weitere Details werden in dieser README-Datei im Kapitel „Semantische Versionierung“ ausführlich erläutert, aber kurz gesagt, wir haben MAJOR.MINOR.PATCH -Versionen von Airflow.
MAJOR Version erhöhtMINOR Version wird erhöht, wenn neue Funktionen hinzugefügt werdenPATCH Version wird erhöht, wenn es nur Fehlerbehebungen und nur dokumentbezogene Änderungen gibt Im Allgemeinen veröffentlichen wir MINOR -Versionen von Airflow von einem Zweig, der nach der MINOR-Version benannt ist. Beispielsweise werden 2.7.* Releases aus v2-7-stable -Zweig veröffentlicht, 2.8.* -Releases aus v2-8-stable -Zweig usw.
Meistens finden in unserem Release-Zyklus, wenn der Branch für den nächsten MINOR -Branch noch nicht erstellt wurde, alle PRs, die mit main zusammengeführt wurden (es sei denn, sie werden zurückgesetzt), ihren Weg in die nächste MINOR -Release. Wenn die letzte Version beispielsweise 2.7.3 ist und v2-8-stable -Zweig noch nicht erstellt wurde, ist die nächste MINOR Version 2.8.0 und alle mit der Hauptversion zusammengeführten PRs werden in 2.8.0 veröffentlicht. Allerdings können einige PRs (Fehlerbehebungen und nur dokumentbezogene Änderungen) beim Zusammenführen in den aktuellen MINOR Zweig übernommen und in der nächsten PATCHLEVEL Version veröffentlicht werden. Wenn beispielsweise 2.8.1 bereits veröffentlicht ist und wir an 2.9.0dev arbeiten, bedeutet das Markieren einer PR mit dem Meilenstein 2.8.2 , dass sie in v2-8-test Zweig ausgewählt und in 2.8.2rc1 veröffentlicht wird. und schließlich in 2.8.2 .
Wenn wir uns auf die nächste MINOR Version vorbereiten, schneiden wir neue v2-*-test und v2-*-stable Zweige ab und bereiten alpha und beta -Releases für die nächste MINOR -Version vor. Die mit der Hauptversion zusammengeführten PRs werden weiterhin in der nächsten MINOR Version veröffentlicht bis rc Version geschnitten ist. Dies geschieht, weil die Zweige v2-*-test und v2-*-stable bei der Vorbereitung der nächsten beta und rc Versionen auf den Hauptzweigen neu basieren. Wenn wir beispielsweise die Version 2.10.0beta1 kürzen, wird alles, was vor der Veröffentlichung von 2.10.0rc1 mit der Hauptversion zusammengeführt wurde, seinen Weg in 2.10.0rc1 finden.
Sobald wir dann den ersten RC-Kandidaten für die MINOR-Version vorbereitet haben, hören wir auf, die Zweige v2-*-test und v2-*-stable zu verschieben, und die mit main zusammengeführten PRs werden in der nächsten MINOR Version veröffentlicht. Allerdings können einige PRs (Fehlerbehebungen und nur dokumentbezogene Änderungen) beim Zusammenführen in den aktuellen MINOR Zweig übernommen und in der nächsten PATCHLEVEL Version veröffentlicht werden – zum Beispiel, wenn die letzte veröffentlichte Version des v2-10-stable -Zweigs 2.10.0rc1 ist 2.10.0rc1 , einige der PRs von main können von Committern als 2.10.0 Meilenstein markiert werden, der Release-Manager wird versuchen, sie in den Release-Zweig aufzunehmen. Bei Erfolg werden sie in 2.10.0rc2 und anschließend in 2.10.0 veröffentlicht. Dies gilt auch für nachfolgende PATCHLEVEL Versionen. Wenn beispielsweise 2.10.1 bereits veröffentlicht ist, bedeutet das Markieren eines PR mit dem Meilenstein 2.10.2 , dass es in den Zweig v2-10-stable ausgewählt und in 2.10.2rc1 und schließlich in 2.10.2 veröffentlicht wird.
Die endgültige Entscheidung über das Rosinenpicken trifft der Release-Manager.
Das Markieren von Problemen mit einem Meilenstein ist etwas anders. Betreuer markieren Probleme normalerweise nicht mit einem Meilenstein, normalerweise werden sie nur in PRs markiert. Wenn PR, die mit dem Problem verknüpft ist (und es „behebt“), nach dem oben beschriebenen Prozess zusammengeführt und in einer bestimmten Version veröffentlicht wird, wird das Problem automatisch geschlossen, es wird kein Meilenstein für das Problem festgelegt, Sie müssen das PR überprüfen Das Problem wurde behoben, um zu sehen, in welcher Version es veröffentlicht wurde.
Allerdings kennzeichnen Betreuer manchmal Probleme mit einem bestimmten Meilenstein, was bedeutet, dass das Problem wichtig ist, um ein Kandidat zu werden, der einen Blick darauf wirft, wenn die Veröffentlichung vorbereitet wird. Da es sich um ein Open-Source-Projekt handelt, bei dem grundsätzlich alle Mitwirkenden ihre Zeit ehrenamtlich zur Verfügung stellen, gibt es keine Garantie dafür, dass ein bestimmtes Problem in einer bestimmten Version behoben wird. Wir möchten die Veröffentlichung nicht zurückhalten, weil ein Problem nicht behoben ist. Daher weist der Release-Manager in einem solchen Fall solche nicht behobenen Probleme dem nächsten Meilenstein zu, falls sie nicht rechtzeitig für die aktuelle Version behoben werden. Daher ist der Meilenstein für ein Problem eher eine Absicht, die man sich ansehen sollte, als ein Versprechen, dass es in der Version behoben wird.
Weiteren Kontext und FAQ zum Patchlevel-Release finden Sie im Dokument „Was gehört zum nächsten Release“ im Ordner dev des Repositorys.
Ja! Halten Sie sich unbedingt an die Markenrichtlinien der Apache Foundation und das Apache Airflow Brandbook. Die aktuellsten Logos finden Sie in diesem Repo und auf der Website der Apache Software Foundation.
Die CI-Infrastruktur für Apache Airflow wurde gesponsert von:
