I am also +1 for dropping 3.9 support early. That can save a lot of
boilerplate for __future__ for type hints as well.
As well as Ash sais we would most probably anyway only support 3.0 and
3.1 with 3.9
And I can say, migrating Python from 3.8 straight into 3.12 was only
generating one bug in our environment, else all was un-noticed.
On 07.02.25 13:51, Ash Berlin-Taylor wrote:
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?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
For additional commands, e-mail: dev-h...@airflow.apache.org
