The purpose of this document is to capture all the key elements which need to be done in order to release Airflow 2.0 to the world. The scope and timing shown here is a "statement of intent", primarily for transparency and visibility to the community about the goals for Airflow 2.0 and the progress being made. This is a "living document" in that it is being updated every week as a result of ongoing progress. 

Functional scope: 

We have effectively finalized the scope of Airflow 2.0 and now actively workings towards merging all the code and getting it released. The big functional elements are listed below:

  1. Scheduler HA - Improve Scheduler performance and reliability (AIP-15)
  2. Airflow REST API (AIP-32)
  3. Functional DAGs (AIP-31)
  4. Production-ready Docker Image (AIP-26)
  5. Providers Package (AIP-21)
  6. Simplified Kubernetes Executor and KubePodOperator
  7. Smart Sensor PR (AIP-17) as an "early access" feature. 
  8. Improvements to SubDAGs (AIP-34): Task Groups as an alternative to SubDAGs and a future replacement

The following functional elements were discussed and deferred to a later (post 2.0) release:

  • DAG Versioning
  • Schedule Interval / Execution at Start of Schedule or End of Schedule
  • Production-ready Helm Chart (part of AIP-26)

The current status of the above in-scope items with respect to code needed to be merged into master:

Scheduler HA (AIP-15)Merged.
REST API (AIP-32)Merged.
Functional DAGs (AIP-31)Merged.
Providers Package (AIP-21)Merged. Being released independently as intended.
Simplified Kubernetes Executor and KubePodOperatorMerged
Smart Sensors (AIP-17)Merged
Task Groups - Improvements to SubDAGs (AIP-34)Merged

The major upcoming milestones are detailed below. As stated above, please note that these are statements of intent, rather than absolute.

Week of 7 Sep 2020Create the 2.0.0-test branch - Done.

While the scope is fluid, we would be rebasing this test branch from master. After we completely freeze the scope, we would only cherrypick commits from Airflow Master to v2-0-test branch if they are “in-scope”. Normal development would continue on Master branch i.e. PRs would be created against Airflow Master.

Week of 12 Oct 2020

First Airflow 2.0 alpha release "apache-airflow-2.0.0.a1" cut on Oct 13th.

Week of 26 Oct 2020Second Airflow 2.0 alpha release "apache-airflow-2.0.0.a2" cut on Oct 26th.
Week of 9 Nov 2020

Cut first 2.0 beta release. First beta build cut on Nov 9th.

Beta snapshots would be published to the Airflow Community to test and create issues to make sure Airflow is functioning and backwards compatible outside of known changes. 

10 Nov  - 7 Dec 

Cut beta releases approximately every Tuesday.

Latest beta build is beta3, cut on Nov 18th and available for testing.

Weeks of 16 Nov and 23 Nov 2020

Cut bridge release based on 1.10.x - jump-off point to 2.0 and submit for vote. Release candidate 1.10.13rc1 submitted for vote on Nov 20th.

Release the 1.10.13 "bridge release" after vote is concluded. Released on 25th Nov.

Upgrade check scripts released independently. Release candidate of Upgrade check scripts cut and submitted for vote on Nov 20th.

Release the upgrade check scripts after vote is concluded. Airflow Upgrade Checks 1.0.1 released on 25th Nov.

Week of 30 Nov 2020

Cut bridge release 1.10.14 to resolve bug found in 1.10.13 after release and submit for vote. 

Expected release the following week.

Week of 7 Dec 2020

Cut first 2.0 release candidate (2.0.0rc1) and submit for vote.
Airflow 2.0.0rc1 release cut and submitted for vote on 9th Dec. 

Airflow Providers release 1.0.0rc1 cut and submitted for vote on 9th Dec. 

Airflow 1.10.14 released on 10th Dec.

Airflow Upgrade Check release 1.1.0rc1 cut and submitted for vote on 11th Dec. 

As part of creating the release candidate, an official vote of 3 working days would be started to release 2.0.0. If there are any bugs discovered in 2.0.0rc1, they will be fixed and a new release candidate will be published.  This will be repeated until the Vote passes.

Week of 14 Dec 2020

Based on votes passing, officially release Airflow 2.0.0, the Providers packages, and the Upgrade scripts. 

Due to bugs found, we had to cut additional release candidate builds.

Airflow 2.0.0rc3 is now the latest release candidate. This was submitted for vote on December 14th. 

Airflow 2.0.0 released on December 17! 


In the interest of clarity, the core approach is detailed below:

  1. Semantic versioning
    Since Airflow has adopted Semantic versioning, this is the opportunity to make significant changes to Airflow, including deprecating functionality and breaking changes. 

  2. Deprecate, don’t break 
    However, the key principle should be to deprecate functionality but not to break existing functionality. 

  3. Backwards compatibility 
    As far as possible, this release should be backwards compatible. If it is not possible to be backwards compatible, this should be flagged and ideally automatically migrated through a utility (which could be an add-on). 

Non-functional scope: 

We also need to establish the non-functional elements needed for a “major release” such as this.

One of the most important elements here is to make the upgrade from Airflow 1.10.x to Airflow 2.0 as straight forward as possible. This includes the following elements:

  1. Capturing all the changes which are needed by the Airflow user in making the transition:
    • Connections (making them unique)
    • Changes to be made to the configuration file
    • Changes to be made to DAGs
    • Changes to the installation mechanism: Providers, Plugins etc.
  2. Upgrade check scripts:
    • “Am I ready” to migrate to Airflow 2.0?
    • These scripts are targeted from 1.10.13 the "bridge release" to 2.0
  3. Migration tools / scripts:
    • Ideally some scripts which can enable automation in the process of upgrading from Airflow 1.10.13 to 2.0, to reduce the possibility of errors. 
  4. Upgrade to 2.0 docs:
    • Create a separate "Upgrade to 2.0" document and split it from guide. 
    • This will cover both what is covered in the upgrade checks scripts as well as other manual changes required either immediately or over time
  5. Unavoidable manual changes to take advantage of new functionality
    • Migrating from the “experimental” API to the new REST API. The experimental API will be deprecated and migration to the new REST API is strongly encouraged.
    • However, the new REST API implements authorization (similar to the UI), so invocation of the API will be a little different from before.

Since this is a significant body of work, the "upgrade check scripts" and the "migration tools" will be versioned independently of the core Airflow release, so that these utilities can be improved on an ongoing basis, without requiring an Airflow release. We anticipate that these utilities will continue to improve even after Airflow 2.0 is released, based on feedback. 

The other important element which is being worked on parallel is improving the overall documentation around Airflow including changes to make the docs-site cleaner and more organized. That effort will be ongoing and is not covered here as part of the Airflow 2.0 plan. 

Github Issues:

To track the progress of work, we use:

Release definitions

As requested, Alpha and Beta release thinking is elaborated here:

Alpha release

  • Integrated build with all main features included.
  • Intended for the developer community:
    • To be used to make sure that there are no regressions and that all the new features added are still working as expected
    • To be used to perform end to end testing
    • To be used to perform benchmarks to be published as feasible
  • Not intended for end users, since this may still contain serious errors and instability. 

Beta release:

  • Functionally complete and all features frozen.
  • Has been tested by the developer community and no critical issues are open. 
  • Beta release is stable and can be used by end user community in "real world" scenarios, though production usage is not recommended.
  • Ideally, should include guides to cover changes in setup, system migration, and DAG migration from 1.10.x. 
  • Benchmarks to be run and published.

Dev Calls

To agree, stay aligned to the process and track the progress of Airflow 2.0 we should have regular calls between Airflow Develops (PMC Members, Committers and whoever is willing to help in Airflow 2.0).


  • No labels


  1. Thanks Vikram Koka for the update. This is really good clarification

  2. Thanks for the info Vikram Koka. landed upon your blog other day (smile) nice work!