This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Page tree
Skip to end of metadata
Go to start of metadata

Future Development Roadmap

As each item, and parts of each item on Airflow's future development is completed, the features are landed in the master branch, for inclusion in the next stable release of Airflow. Development in master is ongoing, in parallel to our stable releases, and new features always land on master first.

General information

The regular Airflow release cycle intends a new release series every six month. Each release series then enters into maintenance mode when the next major release version (1.x.0) comes out as the new current stable release series. Beyond this point, the series is discontinued (EOL)

That means, a series is 

  • six months fully supported,
  • another six months in the maintenance mode,

In total, each series is maintained for a period of approximately 12 months.


If 1.8 is the current release series, then 1.7 would be in maintenance mode. The support of 1.7 would be stopped with the release of 1.9.0.

Each series can have any number of desired minor releases. Any discontinued (EOL) series will not receive any further updates.

seriesgit-branchstatusstartedmaintenancediscontinued (EOL)
2.0 (details)masternew upcoming

1.10 (details)v1-10-stablecurrent stable release series2018-06-19

1.9 (details)v1-9-stable
1.8 (details)v1.8-stable
1.7 (non apache)airbnb_rb1.7.1_4pre-apache migration2016-06-13**2017-03-19

** Will not be maintained, due to incompatibilities with the Apache licensing


The mode describes the status of the release series. The following modes exist:

  • Upcoming Release
  • Current Stable Release
  • Maintenance Mode
  • Discontinued

Upcoming Release

This is the new upcoming release branch. It's not ready for production. The branch is created when the first Release candidate becomes available for testing, otherwise development happens in our master GIT branch.

Blocker bugs and time rather than feature based releases

Releases are made to a time-fixed schedule, so not all bugs found during testing will cause the release to be held back. Blocker bugs are those few that meet the criteria for stopping a release candidate from becoming a release.

Current Stable Release

This is the current release branch. Available bug fixes will be included in the regular bug fix releases. Bug fix releases will be shipped on a as needed basis. New features or parameters will be added to major releases only and not within a release cycle (there might be rare exceptions).

Maintenance Mode

Maintenance mode means that there are regular bug fix releases to address major issues and security issues. Less patches are backported to this branch than to the current release series.

Discontinued (End of Life)

There won't be any other versions of this release series.

Release Branch Checkin Procedure

The release branch is created at the time of the first release candidate.

The release branches are closed to direct checkin as soon as they are created, so for all branches, only bug fixes are allowed into the branch, according to the following procedure:

  • Every bug that is to be patched in a closed branch needs to be associated with a bug report in the Airflow Jira
    • If the bug is a regression that qualifies as blocker bug to hold back a major release, ensure it marked as a regression and has the correct milestone set.
  • The patch for the bug should already be in master, if possible. 
  • Open the bug before making the commit into master, if it is expected that this patch will need to be backported.
  • Once Travis' build has passed and in master on incubator-airflow.git, it should be cherry-picked from master to the branch using git cherry-pick -x and git format-patch -1.
    • The cherry-pick -x adds the (cherry-picked from XXXXX) marker, which allows tracing of patch history though the different branches
  • Add BUG tags to patches that do not already have them
    • The bug should be ASSIGNED, reopen it if the bug is already closed.
    • It is acceptable to file a bug at this stage if one does not already exist.
  • The developer of the patch needs to convince the community that the bug is critical enough to be included in a closed branch.
    • This is done by discussing it on the mailinglist with a vote uploaded patch.
  • The Release Manager applies the patch from bugzilla only if the patch has been signed off.
    • The Release Manager then closes the bug when the patches have landed in all appropriate branches.
  • No labels