This page seeks to describe Airflow's policy for blocking the release of an Airflow version, in particular a new major release.

Time based releases

As Airflow is developed on a time-based release policy, missing or incomplete features will not cause a release to be delayed. It follows that features being landed in master should be landed in a way that moves the project forward, ideally be built of smaller parts that are useful and complete in their own right, and not be enabled by default until they are ready for use.

Bugs in Releases

All bugs are important

It is vital that bugs in Airflow are reported in Jira, and assigned a correct severity.

Regressions

Regressions, that is bugs that are present in new versions of Airflow, in existing features, that are not present in older versions, are very important to the community of Airflow and are addressed as a priority.

Blocking Major releases

The criteria for holding back a release candidate from becoming a final release is that the bug has a severity marked as regression, and is assigned the milestone the same target version as the release.

The bug must truly be a regression, that is not present in the current production release of Airflow. Regressions discovered in older versions but still present in the release candidate are important, but do not count for this rule.

Why do critical bugs not block a release?

The Airflow community cares deeply about producing new Airflow versions that are not only of high quality, but on time. If an issue is important, then developers do address it as they are able, but sometimes issues are complex or maintainers are unavailable in a specific timeframe. If an issue is already present in a released version, and the upgrade doesn't make the situation any worse, blocking the release would deny new features and unrelated fixes to other users.


  • No labels