potiuk commented on PR #29106: URL: https://github.com/apache/airflow/pull/29106#issuecomment-1400839091
@pierrejeambrun - @raphaelauv - yes, what we have now is correct approach - we do not change the supported versions of Python and Kubernetes versions in the Patchlevel releases (so once minor 2.N line is started, it will continue supporting the versions that were used in 2.N.0 till the last 2.N.x release). This is a deliberate choice - we want to make sure that users can release all patchlevel releases for their current "minor" line without any hassle at all. Changing supported Python/K8S might mean that in order to install latest patchlevel the user would have to upgrade Python or K8S and we do not want that. Also our CI supports that - since the https://github.com/apache/airflow/pull/28320 and https://github.com/apache/airflow/pull/28168 were not cherry-picked, the tests we run in v2-5 continue using the same Python & Kubernetes versions for tests, so we can guarantee they work. From https://github.com/apache/airflow#support-for-python-and-kubernetes-versions > We drop support for Python and Kubernetes versions when they reach EOL. Except for Kubernetes, a version stays supported by Airflow if two major cloud providers still provide support for it. We drop support for those EOL versions in main right after EOL date, and it is effectively removed when we release the first new MINOR (Or MAJOR if there is no new MINOR version) of Airflow. For example, for Python 3.7 it means that we will drop support in main right after 27.06.2023, and the first MAJOR or MINOR version of Airflow released after will not have it. -- 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-unsubscr...@airflow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
