airflow
Apache Airflow 2.10.3
Apache Airflow (atau hanya Airflow) adalah platform untuk menulis, menjadwalkan, dan memantau alur kerja secara terprogram.
Ketika alur kerja didefinisikan sebagai kode, alur kerja tersebut menjadi lebih mudah dipelihara, dapat dibuat versinya, dapat diuji, dan kolaboratif.
Gunakan Airflow untuk menulis alur kerja sebagai grafik asiklik terarah (DAG) tugas. Penjadwal Airflow menjalankan tugas Anda pada serangkaian pekerja sambil mengikuti dependensi yang ditentukan. Utilitas baris perintah yang kaya memudahkan melakukan operasi kompleks pada DAG. Antarmuka pengguna yang kaya memudahkan untuk memvisualisasikan pipeline yang berjalan dalam produksi, memantau kemajuan, dan memecahkan masalah bila diperlukan.
Daftar isi
Aliran udara berfungsi paling baik dengan alur kerja yang sebagian besar statis dan berubah secara perlahan. Ketika struktur DAG serupa dari satu proses ke proses berikutnya, hal ini memperjelas unit kerja dan kontinuitas. Proyek serupa lainnya termasuk Luigi, Oozie dan Azkaban.
Airflow biasanya digunakan untuk memproses data, namun berpendapat bahwa tugas idealnya harus idempoten (yaitu, hasil tugas akan sama, dan tidak akan membuat data duplikat di sistem tujuan), dan tidak boleh meneruskan data dalam jumlah besar dari satu tugas ke tugas berikutnya (meskipun tugas dapat meneruskan metadata menggunakan fitur XCom Airflow). Untuk tugas bervolume tinggi dan intensif data, praktik terbaiknya adalah mendelegasikan ke layanan eksternal yang berspesialisasi dalam jenis pekerjaan tersebut.
Airflow bukanlah solusi streaming, namun sering digunakan untuk memproses data real-time, menarik data dari aliran secara batch.
Apache Airflow diuji dengan:
| Versi utama (pengembangan) | Versi stabil (2.10.3) | |
|---|---|---|
| ular piton | 3.9, 3.10, 3.11, 3.12 | 3.8, 3.9, 3.10, 3.11, 3.12 |
| Platform | AMD64/ARM64(*) | AMD64/ARM64(*) |
| Kubernet | 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, Inovasi | 8.0, 8.4, Inovasi |
| SQLite | 3.15.0+ | 3.15.0+ |
* Eksperimental
Catatan : MariaDB tidak diuji/direkomendasikan.
Catatan : SQLite digunakan dalam pengujian Airflow. Jangan menggunakannya dalam produksi. Kami merekomendasikan penggunaan SQLite versi stabil terbaru untuk pengembangan lokal.
Catatan : Airflow saat ini dapat dijalankan pada Sistem Operasi yang sesuai dengan POSIX. Untuk pengembangan, ini diuji secara berkala pada Distro Linux yang cukup modern dan macOS versi terbaru. Di Windows Anda dapat menjalankannya melalui WSL2 (Subsistem Windows untuk Linux 2) atau melalui Linux Containers. Upaya untuk menambahkan dukungan Windows dilacak melalui #10388, tetapi ini bukan prioritas utama. Anda sebaiknya hanya menggunakan distro berbasis Linux sebagai lingkungan eksekusi "Produksi" karena ini adalah satu-satunya lingkungan yang didukung. Satu-satunya distro yang digunakan dalam pengujian CI kami dan digunakan dalam image DockerHub yang dikelola komunitas adalah Debian Bookworm .
Kunjungi dokumentasi situs web resmi Airflow (rilis stabil terbaru) untuk bantuan dalam menginstal Airflow, memulai, atau mempelajari tutorial yang lebih lengkap.
Catatan: Jika Anda mencari dokumentasi untuk cabang utama (cabang pengembangan terbaru): Anda dapat menemukannya di s.apache.org/airflow-docs.
Untuk informasi lebih lanjut tentang Proposal Peningkatan Aliran Udara (AIP), kunjungi Airflow Wiki.
Dokumentasi untuk proyek dependen seperti paket penyedia, image Docker, Helm Chart, Anda akan menemukannya di indeks dokumentasi.
Kami menerbitkan Apache Airflow sebagai paket apache-airflow di PyPI. Namun menginstalnya terkadang rumit karena Airflow adalah bagian dari perpustakaan dan aplikasi. Library biasanya membiarkan dependensinya tetap terbuka, dan aplikasi biasanya menyematkannya, namun kita sebaiknya tidak melakukan keduanya secara bersamaan. Kami memutuskan untuk menjaga dependensi kami seterbuka mungkin (dalam pyproject.toml ) sehingga pengguna dapat menginstal versi perpustakaan yang berbeda jika diperlukan. Artinya pip install apache-airflow tidak akan berfungsi dari waktu ke waktu atau akan menghasilkan instalasi Airflow yang tidak dapat digunakan.
Namun, agar instalasi dapat diulang, kami menyimpan satu set file batasan yang "dikenal berfungsi" di cabang yatim piatu constraints-main dan constraints-2-0 . Kami menyimpan file batasan yang "dikenal berfungsi" secara terpisah per versi Python mayor/minor. Anda dapat menggunakannya sebagai file batasan saat menginstal Airflow dari PyPI. Perhatikan bahwa Anda harus menentukan tag/versi/cabang Airflow yang benar dan versi Python di URL.
Catatan: Hanya instalasi
pipyang saat ini didukung secara resmi.
Meskipun Airflow dapat diinstal dengan alat seperti Poetry atau pip-tools, keduanya tidak berbagi alur kerja yang sama dengan pip - terutama dalam hal manajemen batasan vs. persyaratan. Menginstal melalui Poetry atau pip-tools saat ini tidak didukung.
Ada masalah umum dengan bazel yang mungkin menyebabkan ketergantungan melingkar saat menggunakannya untuk menginstal Airflow. Silakan beralih ke pip jika Anda mengalami masalah seperti itu. Komunitas Bazel berupaya memperbaiki masalah di this PR <https://github.com/bazelbuild/rules_python/pull/1166> _ jadi mungkin bazel versi terbaru akan mengatasinya.
Jika Anda ingin menginstal Airflow menggunakan alat tersebut, Anda harus menggunakan file batasan dan mengonversinya ke format dan alur kerja yang sesuai yang diperlukan alat Anda.
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 "Untuk informasi tentang menginstal paket penyedia, periksa penyedia.
Apache Airflow adalah proyek Apache Software Foundation (ASF), dan kode sumber resmi kami dirilis:
Mengikuti aturan ASF, paket sumber yang dirilis harus mencukupi bagi pengguna untuk membuat dan menguji rilis asalkan mereka memiliki akses ke platform dan alat yang sesuai.
Ada cara lain untuk menginstal dan menggunakan Airflow. Itu adalah metode "kenyamanan" - ini bukan "rilis resmi" seperti yang dinyatakan oleh ASF Release Policy , namun dapat digunakan oleh pengguna yang tidak ingin membuat perangkat lunak sendiri.
Itu adalah - dalam urutan cara paling umum orang menginstal Airflow:
pip standardocker , menggunakannya di Kubernetes, Helm Charts, docker-compose , docker swarm , dll. Anda dapat membaca lebih lanjut tentang menggunakan, menyesuaikan, dan memperluas gambar di dokumen Terbaru, dan mempelajari detail tentang internal dalam dokumen gambar.Semua artefak tersebut bukanlah rilis resmi, namun disusun menggunakan sumber resmi yang dirilis. Beberapa artefak tersebut merupakan artefak "pengembangan" atau "pra-rilis", dan artefak tersebut ditandai dengan jelas sesuai dengan Kebijakan ASF.
DAGs : Ikhtisar semua DAG di lingkungan Anda.
Grid : Representasi grid dari DAG yang membentang sepanjang waktu.
Grafik : Visualisasi dependensi DAG dan statusnya saat ini untuk proses tertentu.
Durasi Tugas : Total waktu yang dihabiskan untuk berbagai tugas dari waktu ke waktu.
Gantt : Durasi dan tumpang tindih DAG.
Kode : Cara cepat untuk melihat kode sumber DAG.
Mulai Airflow 2.0.0, kami mendukung pendekatan SemVer yang ketat untuk semua paket yang dirilis.
Ada beberapa aturan khusus yang kami sepakati yang menentukan rincian pembuatan versi berbagai paket:
google 4.1.0 dan amazon 3.0.3 dapat dengan senang hati diinstal dengan Airflow 2.1.2 . Jika ada batasan ketergantungan silang antara penyedia dan paket Airflow, batasan tersebut ada di penyedia sebagai batasan install_requires . Kami bertujuan untuk menjaga kompatibilitas penyedia dengan semua versi Airflow 2 yang dirilis sebelumnya, namun terkadang akan ada perubahan yang dapat menyebabkan beberapa, atau semua penyedia, menentukan versi Airflow minimum.Siklus hidup versi Apache Airflow:
| Versi | Patch/Kecil Saat Ini | Negara | Rilis Pertama | Dukungan Terbatas | EOL/Dihentikan |
|---|---|---|---|---|---|
| 2 | 2.10.3 | Didukung | 17 Desember 2020 | TBD | TBD |
| 1.10 | 1.10.15 | EOL | 27 Agustus 2018 | 17 Desember 2020 | 17 Juni 2021 |
| 1.9 | 1.9.0 | EOL | 03 Januari 2018 | 27 Agustus 2018 | 27 Agustus 2018 |
| 1.8 | 1.8.2 | EOL | 19 Maret 2017 | 03 Januari 2018 | 03 Januari 2018 |
| 1.7 | 1.7.1.2 | EOL | 28 Maret 2016 | 19 Maret 2017 | 19 Maret 2017 |
Versi dukungan terbatas hanya akan didukung dengan keamanan dan perbaikan bug kritis. Versi EOL tidak akan mendapatkan perbaikan atau dukungan apa pun. Kami selalu menyarankan agar semua pengguna menjalankan rilis minor terbaru yang tersedia untuk versi mayor apa pun yang digunakan. Kami sangat menyarankan untuk meningkatkan ke rilis utama Airflow terbaru sesegera mungkin dan sebelum tanggal EOL.
Pada Airflow 2.0, kami menyetujui aturan tertentu yang kami ikuti untuk dukungan Python dan Kubernetes. Kebijakan tersebut didasarkan pada jadwal rilis resmi Python dan Kubernetes, yang dirangkum dengan baik dalam Panduan Pengembang Python dan kebijakan kemiringan versi Kubernetes.
Kami menghentikan dukungan untuk versi Python dan Kubernetes saat versi tersebut mencapai EOL. Kecuali Kubernetes, suatu versi tetap didukung oleh Airflow jika dua penyedia cloud besar masih memberikan dukungan untuk versi tersebut. Kami menghentikan dukungan untuk versi EOL tersebut di main tepat setelah tanggal EOL, dan dukungan tersebut secara efektif dihapus saat kami merilis MINOR baru yang pertama (Atau MAJOR jika tidak ada versi MINOR baru) dari Airflow. Misalnya, untuk Python 3.9, ini berarti kami akan menghentikan dukungan di main tepat setelah 27.06.2023, dan Airflow versi MAJOR atau MINOR pertama yang dirilis setelahnya tidak akan memilikinya.
Kami mendukung versi baru Python/Kubernetes di main setelah dirilis secara resmi, segera setelah kami membuatnya berfungsi di pipeline CI kami (yang mungkin tidak langsung berfungsi karena sebagian besar dependensi mengikuti versi baru Python) kami merilis image baru /support di Airflow berdasarkan pengaturan CI yang berfungsi.
Kebijakan ini merupakan upaya terbaik yang berarti mungkin ada situasi di mana kami dapat menghentikan dukungan lebih awal jika keadaan memerlukannya.
Komunitas Airflow menyediakan gambar kontainer yang dikemas dengan mudah yang diterbitkan setiap kali kami menerbitkan rilis Apache Airflow. Gambar-gambar itu berisi:
Versi image OS dasar adalah versi stabil Debian. Airflow mendukung penggunaan semua versi stabil yang aktif saat ini - segera setelah semua dependensi Airflow mendukung pembangunan, dan kami menyiapkan pipeline CI untuk membangun dan menguji versi OS. Sekitar 6 bulan sebelum berakhirnya dukungan reguler untuk versi OS stabil sebelumnya, Airflow mengalihkan image yang dirilis untuk menggunakan versi OS terbaru yang didukung.
Misalnya peralihan dari Debian Bullseye ke Debian Bookworm telah diterapkan sebelum rilis 2.8.0 pada bulan Oktober 2023 dan Debian Bookworm akan menjadi satu-satunya opsi yang didukung pada Airflow 2.10.0.
Pengguna akan terus dapat membuat image mereka menggunakan rilis Debian yang stabil hingga akhir dukungan reguler dan pembuatan serta verifikasi image terjadi di CI kami tetapi tidak ada pengujian unit yang dijalankan menggunakan image ini di cabang main .
Airflow memiliki banyak ketergantungan - langsung dan transitif, juga Airflow adalah keduanya - perpustakaan dan aplikasi, oleh karena itu kebijakan kami terhadap ketergantungan harus mencakup keduanya - stabilitas instalasi aplikasi, tetapi juga kemampuan untuk menginstal versi dependensi yang lebih baru bagi pengguna yang mengembangkan DAG. Kami mengembangkan pendekatan yang menggunakan constraints untuk memastikan aliran udara dapat dipasang secara berulang, sementara kami tidak membatasi pengguna kami untuk meningkatkan sebagian besar dependensi. Oleh karena itu, kami memutuskan untuk tidak menggunakan dependensi Airflow versi batas atas secara default, kecuali kami memiliki alasan kuat untuk meyakini bahwa versi batas atas diperlukan karena pentingnya ketergantungan serta risiko yang ditimbulkannya untuk meningkatkan ketergantungan tertentu. Kami juga membatasi ketergantungan yang kami tahu menyebabkan masalah.
Mekanisme batasan kami menangani pencarian dan peningkatan semua dependensi non-batas atas secara otomatis (asalkan semua pengujian lulus). Kegagalan build main kita akan menunjukkan jika ada versi dependensi yang merusak pengujian kita - yang menunjukkan bahwa kita harus melakukan upper-bind pada versi tersebut atau bahwa kita harus memperbaiki kode/pengujian untuk memperhitungkan perubahan upstream dari dependensi tersebut.
Setiap kali kita membatasi ketergantungan seperti itu, kita harus selalu berkomentar mengapa kita melakukannya - yaitu kita harus mempunyai alasan bagus mengapa ketergantungan berada pada batas atas. Dan kami juga harus menyebutkan apa syarat untuk melepas ikatan itu.
Ketergantungan tersebut dipertahankan di pyproject.toml .
Ada beberapa dependensi yang menurut kami cukup penting untuk dijadikan batas atas secara default, karena dependensi tersebut diketahui mengikuti skema pembuatan versi yang dapat diprediksi, dan kami tahu bahwa versi baru dari dependensi tersebut kemungkinan besar akan membawa perubahan besar. Kami berkomitmen untuk meninjau secara rutin dan berupaya meningkatkan ke versi dependensi yang lebih baru saat dependensi dirilis, namun ini adalah proses manual.
Ketergantungan penting adalah:
SQLAlchemy : batas atas ke versi MINOR tertentu (SQLAlchemy diketahui menghapus penghentian dan memperkenalkan perubahan yang dapat menyebabkan gangguan terutama dukungan untuk Basis Data yang berbeda bervariasi dan berubah pada berbagai kecepatan)Alembic : penting untuk menangani migrasi kita dengan cara yang dapat diprediksi dan berkinerja baik. Ini dikembangkan bersama dengan SQLAlchemy. Pengalaman kami dengan Alembic sangat stabil dalam versi MINORFlask : Kami menggunakan Flask sebagai tulang punggung UI dan API web kami. Kami tahu bahwa versi utama Flask kemungkinan besar akan memperkenalkan perubahan yang dapat menyebabkan gangguan pada semua versi tersebut, jadi membatasinya pada versi UTAMA adalah hal yang masuk akalwerkzeug : perpustakaan diketahui menyebabkan masalah pada versi baru. Ini terkait erat dengan perpustakaan Flask, dan kita harus memperbaruinya bersama-samacelery : Seledri adalah komponen penting dari Airflow seperti yang digunakan untuk CeleryExecutor (dan sejenisnya). Seledri mengikuti SemVer, jadi kita harus membatasinya ke versi UTAMA berikutnya. Selain itu, saat kita menggunakan versi teratas perpustakaan, kita harus memastikan versi Airflow minimum Penyedia Seledri diperbarui.kubernetes : Kubernetes adalah komponen penting dari Airflow karena digunakan untuk KubernetesExecutor (dan sejenisnya). Pustaka Python Kubernetes mengikuti SemVer, jadi kita harus membatasinya ke versi UTAMA berikutnya. Selain itu, ketika kita mengubah versi atas perpustakaan, kita harus memastikan versi Airflow minimum Penyedia Kubernetes diperbarui.Bagian utama dari Airflow adalah Airflow Core, namun kekuatan Airflow juga berasal dari sejumlah penyedia yang memperluas fungsionalitas inti dan dirilis secara terpisah, meskipun kami menyimpannya (untuk saat ini) dalam monorepo yang sama demi kenyamanan. Anda dapat membaca selengkapnya tentang penyedia di dokumentasi Penyedia. Kami juga telah menerapkan serangkaian kebijakan untuk mempertahankan dan melepaskan penyedia yang dikelola masyarakat serta pendekatan untuk penyedia komunitas vs. pihak ketiga dalam dokumen penyedia.
Ketergantungan extras dan providers tersebut dipertahankan di provider.yaml masing-masing penyedia.
Secara default, kita tidak boleh memiliki ketergantungan batas atas untuk penyedia, namun masing-masing pengelola penyedia mungkin memutuskan untuk menambahkan batasan tambahan (dan membenarkannya dengan komentar).
Ingin membantu membangun Apache Airflow? Lihat panduan kontributor kami untuk ikhtisar komprehensif tentang cara berkontribusi, termasuk petunjuk penyiapan, standar pengkodean, dan pedoman permintaan tarik.
Jika Anda tidak sabar untuk berkontribusi, dan ingin memulai secepatnya, lihat panduan memulai kontribusi di sini!
Gambar Docker (kontainer) resmi untuk Apache Airflow dijelaskan dalam gambar.
+1s anggota PMC dan pelaku dianggap sebagai suara yang mengikat. Kami mengetahui sekitar 500 organisasi yang menggunakan Apache Airflow (tetapi kemungkinan masih banyak lagi) di alam liar.
Jika Anda menggunakan Airflow - jangan ragu untuk membuat PR untuk menambahkan organisasi Anda ke daftar.
Airflow adalah pekerjaan komunitas, namun pembuat/pengelola inti bertanggung jawab untuk meninjau dan menggabungkan PR serta mengarahkan percakapan seputar permintaan fitur baru. Jika Anda ingin menjadi pengelola, harap tinjau persyaratan pengimplementasi Apache Airflow.
Seringkali Anda akan melihat masalah yang ditetapkan ke pencapaian tertentu dengan versi Airflow, atau PR yang digabungkan ke cabang utama dan Anda mungkin bertanya-tanya di rilis mana PR gabungan akan dirilis atau rilis mana yang akan menjadi masalah yang diperbaiki. di. Jawabannya seperti biasa - tergantung pada berbagai skenario. Jawabannya berbeda untuk PR dan Isu.
Untuk menambahkan sedikit konteks, kami mengikuti skema pembuatan versi Semver seperti yang dijelaskan dalam proses rilis Airflow. Rincian lebih lanjut dijelaskan secara rinci dalam README ini di bawah bab pembuatan versi Semantik, tetapi singkatnya, kami memiliki Airflow versi MAJOR.MINOR.PATCH .
MAJOR bertambah jika terjadi perubahan yang menggangguMINOR bertambah ketika ada fitur baru yang ditambahkanPATCH bertambah ketika hanya ada perbaikan bug dan perubahan hanya pada dokumen Umumnya kami merilis Airflow versi MINOR dari cabang yang diberi nama sesuai versi MINOR. Misalnya rilis 2.7.* dirilis dari cabang v2-7-stable , 2.8.* dirilis dari cabang v2-8-stable , dll.
Seringkali dalam siklus rilis kita, ketika cabang untuk cabang MINOR berikutnya belum dibuat, semua PR yang digabungkan ke main (kecuali jika dikembalikan), akan menemukan jalannya ke rilis MINOR berikutnya. Misalnya jika rilis terakhir adalah 2.7.3 dan cabang v2-8-stable belum dibuat, rilis MINOR berikutnya adalah 2.8.0 dan semua PR yang digabungkan ke main akan dirilis pada 2.8.0 . Namun, beberapa PR (perbaikan bug dan perubahan khusus dokumen) ketika digabungkan, dapat dipilih ke cabang MINOR saat ini dan dirilis pada rilis PATCHLEVEL berikutnya. Misalnya, jika 2.8.1 sudah dirilis dan kita sedang mengerjakan 2.9.0dev , maka menandai PR dengan 2.8.2 berarti bahwa PR tersebut akan dipilih ke cabang v2-8-test dan dirilis di 2.8.2rc1 . dan akhirnya di 2.8.2 .
Saat kami bersiap untuk rilis MINOR berikutnya, kami memotong cabang v2-*-test dan v2-*-stable baru dan menyiapkan rilis alpha , beta untuk versi MINOR berikutnya, PR yang digabungkan ke main akan tetap dirilis di rilis MINOR berikutnya sampai versi rc terpotong. Hal ini terjadi karena cabang v2-*-test dan v2-*-stable didasarkan pada cabang utama ketika rilis beta dan rc berikutnya disiapkan. Misalnya, ketika kita memotong versi 2.10.0beta1 , apa pun yang digabungkan ke main sebelum 2.10.0rc1 dirilis, akan menuju ke 2.10.0rc1.
Kemudian, setelah kami mempersiapkan kandidat RC pertama untuk rilis MINOR, kami berhenti memindahkan cabang v2-*-test dan v2-*-stable dan PR yang digabungkan ke main akan dirilis pada rilis MINOR berikutnya. Namun, beberapa PR (perbaikan bug dan perubahan khusus dokumen) ketika digabungkan, dapat dipilih ke cabang MINOR saat ini dan dirilis pada rilis PATCHLEVEL berikutnya - misalnya ketika versi terakhir yang dirilis dari cabang v2-10-stable adalah 2.10.0rc1 , beberapa PR dari main dapat ditandai sebagai pencapaian 2.10.0 oleh committer, manajer rilis akan mencoba memilihnya ke dalam cabang rilis. Jika berhasil, mereka akan dirilis pada 2.10.0rc2 dan selanjutnya pada 2.10.0 . Hal ini juga berlaku untuk versi PATCHLEVEL selanjutnya. Ketika misalnya 2.10.1 sudah dirilis, menandai PR dengan pencapaian 2.10.2 berarti PR tersebut akan dipilih ke cabang v2-10-stable dan dirilis di 2.10.2rc1 dan akhirnya di 2.10.2 .
Keputusan akhir mengenai pemetikan ceri dibuat oleh manajer rilis.
Menandai masalah dengan pencapaian sedikit berbeda. Pengelola biasanya tidak menandai masalah dengan tonggak sejarah, biasanya masalah tersebut hanya ditandai di PR. Jika PR yang ditautkan ke masalah (dan "memperbaikinya") digabungkan dan dirilis dalam versi tertentu mengikuti proses yang dijelaskan di atas, masalah akan ditutup secara otomatis, tidak ada pencapaian yang ditetapkan untuk masalah tersebut, Anda perlu memeriksa PR yang memperbaiki masalah untuk melihat versi mana yang dirilis.
Namun, terkadang pengelola menandai masalah dengan pencapaian tertentu, yang berarti bahwa masalah tersebut penting untuk dijadikan kandidat untuk dilihat saat rilis sedang dipersiapkan. Karena ini adalah proyek Sumber Terbuka, di mana pada dasarnya semua kontributor menyumbangkan waktunya, tidak ada jaminan bahwa masalah tertentu akan diperbaiki dalam versi tertentu. Kami tidak ingin menunda rilis karena beberapa masalah belum diperbaiki, jadi dalam kasus seperti itu, manajer rilis akan menugaskan kembali masalah yang belum diperbaiki tersebut ke pencapaian berikutnya jika masalah tersebut tidak diperbaiki tepat pada waktunya untuk rilis saat ini. Oleh karena itu, tonggak sejarah masalah ini lebih merupakan niat yang harus diperhatikan, daripada janji bahwa masalah tersebut akan diperbaiki dalam versi tersebut.
Konteks lebih lanjut dan FAQ tentang rilis tingkat patch dapat ditemukan di dokumen Apa yang masuk ke rilis berikutnya di folder dev repositori.
Ya! Pastikan untuk mematuhi kebijakan merek dagang Apache Foundation dan Buku Merek Apache Airflow. Logo terbaru dapat ditemukan di repo ini dan di situs web Apache Software Foundation.
Infrastruktur CI untuk Apache Airflow disponsori oleh:
