Minimum Python policy/upgrade policy?

LLVM Project
#1

Hey,

I was wondering what the policy around the minimum Python version supported is (and when it can be bumped). On Getting Started with the LLVM System — LLVM 16.0.0git documentation 3.6 is mentioned as minimum and is used on buildbot, but 3.6 is already EOL.

– Jacques

#2

I checked the git blame and it was just the switch from Python 2 to Python 3:

#3

Yes so ~2 years ago Python 3.6 was specified as minimum requirement. Can it be bumped now to 3.7 given 3.6 is EOL? Is this a process that is a particular group’s responsibility? (it probably ties in with the other minimum software requirements).

Also do we care enough to have our own process for Python minimum versions vs just following another OSS project like NEP 29 — Recommend Python and NumPy version support as a community policy standard — NumPy Enhancement Proposals or saying minimum version is oldest non end-of-life from Status of Python Versions?

– Jacques

#4

No, anyone can propose an RFC. Usually “it’s old” isn’t quite enough, but I’d think “it’s EOL” would be.

In most cases the minimum requirements are some function of what comes with the major Linux distributions, how easy it is for someone to upgrade, and what benefit/functionality the new version brings.

The CMake minimum, for example, doesn’t really weigh “what comes with” very highly because it’s so simple to download a new version. Maybe Python is easy enough to get newer versions that what’s on the distributions isn’t so important either. I still have an Ubuntu 18.04 box that came with Python 2.6 IIRC, but I also have 3.8 on it and I don’t remember that being a big deal.

#5

For compiler upgrades, there is a policy for upgrades. The last cmake upgrade was just an RFC:

#6

I think an RFC that answers the following questions would be appropriate:

  • What version do you suggest to increase to
  • Why this upgrade? (EOL, new features etc)
  • Where is the pain in keeping the current min version?
  • What (common) dists / OSes would be affected (not have access to this version by default)
  • What’s the process to if you don’t have the right version. For users and developers.

Similar to what we do for toolchain: LLVM Developer Policy — LLVM 16.0.0git documentation

Bonus if we add this to the dev policy and remove the guessing for next bump of dependencies.

#7

Your criteria seem reasonable. They should be documented somewhere.

#8

I think that the release being EOL is not really a strong argument for dropping it without any other good reasons, since “3.6 support” doesn’t mean any of the users are required to run an EOL release. For py3.6, I think it’s the latest one available in CentOS 7 repos and it’s still a major build/target system out there, so I wouldn’t want to bump the version without a clear case on why we can’t keep supporting the current one.

#9

It is. The last toolchain upgrade was mainly feature driven. The update went from C++14 to ++17. The guideline is to support toolchains that are roughly three years old.

3.8 released 2019-10-14.
3.7 released 2018-06-27.

IMHO, an upgrade to 3.8 would be more appropriate. There are several Python tools that would benefit from the features.

[RFC] Upgrading LLVM's minimum required Python version
#10

+1 on following the python end of life schedule. Having that clear cadence has been a really valuable addition and something we should leverage, imo.

While slightly more involved than getting a cmake version, it is still very simple to get basically any python version as a normal user on most systems. Documentation and pointers to one liners can help a lot here, ime.