+1 I'd support dropping EOL python versions from the next / latest flink version. Users who end up on older python versions will need to spend time to update their flink versions and can always continue using older versions until they are ready to upgrade. Dropping old versions on the master branch would certainly help us keep development practices and code standards up-to-date.
On 2025/05/26 14:54:14 Mika Naylor 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
