https://endoflife.date/python for a visual of the versions and their support status for anyone following along.
We do have a published get-out-of-jail card: > This policy is best-effort which means there may be situations where we might > terminate support earlier if circumstances require it. But yes, it shouldn’t be willy-nilly. The only sort of reason/rule I can think of would be “At major version releases, we will support any Python with more than 2 years left of security support” but that feels very arbitrary. The module I want to use is https://docs.cadwyn.dev/ (which I’ve used on other non OSS projects), but thinking about it a bit more, we are likely only going to have one or two versions of the Task Execution API (one with 3.0, and one with 3.1), maybe a couple of more in some patch releases but that is unlikely and I can manually emulate Cadwyn for now and swap over to it around the 3.2/3.3 timeframe. > On 7 Feb 2025, at 12:30, Jarek Potiuk <ja...@potiuk.com> wrote: > > I would be for it - but this should be accompanied with a clear proposal of > the policy we are going to use forward for Airflow 3. We cannot make such > "ad-hoc" decisions based on "I want to use that package". We need to have > solid reasoning and clear indication for our users what kind of support > they can expect for different python versions. They cannot be surprised. > So far our policy was clear - we drop support when Python EOL is reached. > That was easy to explain and justify. I don't have a concrete proposal, but > maybe someone can come up with a rule that we codify and use from now on. > > J. > > On Fri, Feb 7, 2025 at 1:25 PM Ash Berlin-Taylor <a...@apache.org> wrote: > >> Hi all, >> >> I have a proposal that we increase the minimum required python version to >> 3.10, in a slight departure from our published python version req >> https://github.com/apache/airflow?tab=readme-ov-file#support-for-python-and-kubernetes-versions >> >> As a reminder, Python 3.9 is already in security only fixes, and is >> supported only until October 2025, or for roughly 7 months after the >> release of Airflow 3.0. We’d be bringing forward the requirement on Python >> 3.10 from (likely) Airflow 3.2 to 3.0. >> >> We discussed this briefly last July on the Airflow 3 dev calls and the >> conclusion then was to follow the our policy, but I would like to make use >> of a python module in the Task Execution API server that only supports >> Python 3.10+. >> >> Pros of this: We’re more up to date, and I can use this module, rather >> than having to write something myself to handle API versioning >> Cons of this: it might make it harder for some users to update to 3.0 as >> some users would also have to update the Python version before they can >> update the Airflow version. >> >> Looking at the analytics data we had previously collected (which only gets >> data from 2.10.x so is imperfect to be sure), I can see that Python 3.10+ >> accounts for about 77% of the data. So it’s certainly not nothing. (5% are >> still on 3.8, and 17% are on 3.9) >> >> I’m really not sold one way or another on this, so I thought I’d discuss >> it with the wider community. >> >> What do you all think?
