Solid +1 for dropping instead of deprecate. Best, Ferenc
On Wednesday, May 28th, 2025 at 07:12, Gabor Somogyi <gabor.g.somo...@gmail.com> wrote: > > > Hi Mika, > > +1 to drop and not just deprecate from my side. > > BR, > G > > > On Wed, May 28, 2025 at 7:06 AM Dian Fu dian0511...@gmail.com wrote: > > > Hi Mika, > > > > Thanks for bringing up this discussion. > > > > Regarding dropping support of Python 3.8: +1 for this. Since we will > > add support for Python 3.12 in Flink 2.1[1], this means we need to > > maintain 5 Python versions if we still support Python 3.8. Considering > > that 3.8 is already EOL and the issue you encountered, it makes sense > > to me to drop support for it in Flink 2.1. Besides, I see that many > > other Python libraries have dropped the support of Python 3.8 in the > > latest releases, e.g. Pandas, Numpy, Apache Beam, PySpark, Ray, etc. > > > > > We have some sort of policy or intuition around deprecating/dropping > > > support for Python versions to make maintenance burden a little easier, > > > and > > > whether this should be based on languages reaching eol, wider language > > > version usage or whether we have insight into what python versions those > > > on > > > the latest Flink versions are using. > > > > There are still no such policies for now. In the past, we proposed to > > drop the EOL Python versions when adding support for new Python > > versions. This also make sure it doesn't bring too much burden for the > > testing (It needs to test against all Python versions in the nightly > > tests). From what I see in other Python projects, they usually > > maintain 3 to 4 Python versions in practice. This is the same case for > > PyFlink in practice. > > > > > Whether we should deprecate the version first (like in FLINK-28195[3]), > > > and how many minor versions this deprecation should exist for before > > > dropping altogether (just one?) > > > Kind regards, > > > > I'm slightly inclined to just drop it considering the issue you > > encountered and Python 3.8 was already EOL half a year ago. > > > > Regards, > > Dian > > > > [1] https://issues.apache.org/jira/browse/FLINK-37823 > > > > On Mon, May 26, 2025 at 10:55 PM Mika Naylor m...@autophagy.io.invalid > > wrote: > > > > > Hi all, > > > > > > I recently wanted to look into using the new dependency groups mechanism > > > for centralising testing/development requirements in one place in a > > > consistent format, rather than scattered in various places. I opened > > > FLINK-37775 to reflect this, but had to drop it as it's only a feature in > > > new versions of pip, and new pip versions are no longer being released for > > > our minimum Python version, 3.8. > > > > > > 3.8 is officially end of life as of last year[1], but is still used[2]. > > > With 3.8 at EOL, and 3.9 reaching it end of this year, I wanted to ask for > > > feedback on whether: > > > > > > • We have some sort of policy or intuition around deprecating/dropping > > > support for Python versions to make maintenance burden a little easier, > > > and > > > whether this should be based on languages reaching eol, wider language > > > version usage or whether we have insight into what python versions those > > > on > > > the latest Flink versions are using. > > > • Whether we should deprecate the version first (like in > > > FLINK-28195[3]), and how many minor versions this deprecation should exist > > > for before dropping altogether (just one?) > > > Kind regards, > > > Mika > > > > > > [1] https://devguide.python.org/versions/ > > > [2] https://w3techs.com/technologies/history_details/pl-python/3 > > > [3] https://issues.apache.org/jira/browse/FLINK-28195
