You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
How many versions back are we going to support. We need to have a written and announced policy about it after we agree it so that our users know what to expect.
Are we also thinking of being able to use old airflow-core with new task-sdk? Or do we plan to have strict relation that task-sdk in concreate version will require airflow-core>=X.Y.0?
In both cases I think we should also implement some way of checking it and rejecting incompatible versions on both sides. Eventually task-sdk will be installed without airflow-core and they will be running on different machines, so we cannot really add "requirements" in Python packages, but I think we should have a runtime check implemented to check both - airflow-core version in task-sdk, and task-sdk version in airflow (during the api communication). This is the only way to avoid some difficult issues where "slight" incompatibility we did not test for could cause some undesired side effect.
I think basica assumption should be that "if we do not test it in CI, it does not work" and we should forbid those things we did not test things for (same as we do now for providers - but there we do it with "min airflow version" in providers.
Activity
potiuk commentedon Jul 11, 2025
Three questions.
How many versions back are we going to support. We need to have a written and announced policy about it after we agree it so that our users know what to expect.
Are we also thinking of being able to use old airflow-core with new task-sdk? Or do we plan to have strict relation that task-sdk in concreate version will require airflow-core>=X.Y.0?
In both cases I think we should also implement some way of checking it and rejecting incompatible versions on both sides. Eventually task-sdk will be installed without airflow-core and they will be running on different machines, so we cannot really add "requirements" in Python packages, but I think we should have a runtime check implemented to check both - airflow-core version in task-sdk, and task-sdk version in airflow (during the api communication). This is the only way to avoid some difficult issues where "slight" incompatibility we did not test for could cause some undesired side effect.
I think basica assumption should be that "if we do not test it in CI, it does not work" and we should forbid those things we did not test things for (same as we do now for providers - but there we do it with "min airflow version" in providers.
task-sdkdependency fromairflow-core#62061