Airflow 2.0 - Planning

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:

Next steps

The immediate action items with respect to scope and major milestones are:

1. Testing of the second 2.0.0alpha build.
2. Fix bugs as they are raised with alpha builds.
3. Cut the beta build.
4. Documentation for "Getting started with 2.0 and upgrading to 2.0" to enable beta testing, as well as for 2.0 once released. Also, enhance the upgrade check scripts as needed.
5. Close out release management related open items with respect to release of Providers packages. Not necessarily needed for beta1, but before RC. 

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

Approach

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. These include:

1. Capturing changes which are needed:
   
   • Connections (making them unique)
• Changes to be made to the configuration file
• Changes to be made to DAGs / SubDags?
• Changes to the installation mechanism: Providers, Plugins etc.
• Changes to any other core concepts
2. Migration tools:
• “Am I ready” to migrate to Airflow 2.0?
• Upgrade configurations, etc. from 1.xx to 2.0
3. Manual changes to migrate/upgrade
• Migrating from “experimental” to new API
4. Testing
   
5. Docs
• Updating.md guide especially needs to cover what the migration script does and more comprehensive and easily readable
• Make docs-site cleaner and more organized

Github Issues:

To track the progress of work, we use:

• Meta-issue: Release Airflow 2.0 #10152
• Milestone: "Airflow 2.0" milestone 

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).

Calendar: