r-richmond opened a new issue #16426: URL: https://github.com/apache/airflow/issues/16426
**Description** * Allow providers to specify which python versions they support; (Core-airflow would also have its own supported versions) * Don't run tests for providers on python versions that aren't marked as supported **Use case / motivation** * Due to the success of airflow it now has a huge selection of providers and packages that those providers depend upon. Unfortunately due to this huge selection updating airflow to supporting new versions of python is becoming a larger and larger task and is currently unbounded in terms of complexity. * The current situation has led to the python 3.9 PRS languishing for ~8 months (starting 2020-10-29). Worse yet the current blocker was unknown [until today](https://github.com/apache/airflow/pull/15515#issuecomment-860264240) due to the complexity of PIP extras dependencies. * Put succinctly It feels suboptimal to be [waiting](https://github.com/dropbox/PyHive/issues/380#issuecomment-860263187) for dropbox/3rdparty to update a package for a provider that many/most airflow users do not want or need. **End Result** 1. This will allow us to incrementally support new versions of python rather than requiring all providers support the new version before we can migrate any. ~ @ashb [Link](https://github.com/apache/airflow/pull/11950#issuecomment-784540464) 1. Allow endusers to update Airflow on a more regular cadence if their desired providers are ready. **Are you willing to submit a PR?** Unfortunately, it is beyond my abilities **Related Issues** 1. https://github.com/apache/airflow/pull/11950 1. https://github.com/apache/airflow/pull/15515 -- 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. For queries about this service, please contact Infrastructure at: [email protected]
