You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by "amoghrajesh (via GitHub)" <gi...@apache.org> on 2025/07/11 08:13:34 UTC

[I] Task SDK compat tests with Airflow core [airflow]

amoghrajesh opened a new issue, #53171:
URL: https://github.com/apache/airflow/issues/53171

   ### Body
   
   We should be testing atleast n and n-1 version of task SDK with airflow core. This ensures backcompat.
   
   ### Committer
   
   - [x] I acknowledge that I am a maintainer/committer of the Apache Airflow project.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] Task SDK compat tests with Airflow core [airflow]

Posted by "potiuk (via GitHub)" <gi...@apache.org>.
potiuk commented on issue #53171:
URL: https://github.com/apache/airflow/issues/53171#issuecomment-3061562864

   Three questions.
   
   1) 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.
   
   2) 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?
   
   3) 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. 
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@airflow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org