macOS version support policy

Core Development
21

The oldest Python with a binary installer is 3.13:

  • 3.13 requires 10.13 High Sierrra or later
  • 3.14 and 3.15 require 10.15 Catalina or later

I did a very similar analysis a couple of days ago on a week’s worth of urllib3 downloads and got very similar results:

Details
version codename downloads percentage cumulative users >=version
10.11 El Capitan 20 0.00% 0.00% 100.00%
10.12 Sierra 25 0.00% 0.00% 100.00%
10.13 High Sierra 336 0.01% 0.01% 100.00%
10.14 Mojave 335 0.01% 0.02% 99.99%
10.15 Catalina 4,328 0.14% 0.16% 99.98%
10.16 Big Sur 64,734 2.05% 2.21% 99.84%
11 Big Sur 10,028 0.32% 2.53% 97.79%
12 Monterey 74,529 2.36% 4.89% 97.47%
13 Ventura 103,134 3.27% 8.16% 95.11%
14 Sonoma 372,236 11.80% 19.96% 91.84%
15 Sequoia 1,549,977 49.15% 69.12% 80.04%
16 101 0.00% 69.12% 30.88%
17 45 0.00% 69.12% 30.88%
18 45 0.00% 69.12% 30.88%
26 Tahoe 973,712 30.87% 99.99% 30.88%
27 208 0.01% 100.00% 0.01%
sum 3,153,793 100.00%

Which means:

  • 3.13’s 10.13+ accounts for ~100.00% (99.9955% for requests)
  • 3.14 and 3.15’s 10.15+ accounts for 99.98% (99.96% for requests)
1 Like
22

I don’t think anyone is really going to argue with the raw numbers. Our own stats indicate that the oldest macOS version with a significant number of users is 10.11, though there are a vocal minority using something older.

It makes sense to use a recent deployment target for binaries, and it makes sense for core developers to spend their time on things that will benefit the most people. I think the only question is how to handle the situation where someone else is willing to put in the work to fix things on the older OS versions.

1 Like
23

this is already covered in PEP 11 – CPython platform support | peps.python.org . We’re free to reject such changes if they are invasive or cause a maintenance burden.

24

Every change comes with some amount of maintenance burden. How is a potential contributor to gauge the likelihood of a change being accepted? Or, perhaps it’s easier to give an example of a change that fixes a problem that only affects macOS < 10.13 that would be accepted?

25

The steering council just approved a change to PEP 11; see the new Unsupported platforms section.

The core team does not develop and test on such platforms, and so they cannot provide any promises that Python will work on them.

However, the code base does include unsupported code – that is, code specific to unsupported platforms. Contributions in this area are welcome as long as they:

  • pose a minimal maintenance burden to the core team, and
  • benefit substantially more people than the contributor.

We assume contributors are able to maintain modifications/patches, test patched builds, redistribute modified code, make promises to their users, and otherwise support “their” platform. With that in mind, it is generally unnecessary to backport unsupported fixes to CPython’s maintenance branches.

(Read the whole thing for more details.)

Basically: if you can maintain a GitHub fork of CPython, or just a public set of patches that make it work on old Macs? You pretty much need that to test such patches, which the CPython team can’t do.

As an example of something that would be accepted: adding another entry to a list of platform-specific ifs, like say here.

26

Thanks, that pretty much says what I gathered to be the case until recently. I didn’t want to point fingers at anyone, but I guess it’s unnecessarily oblique not to acknowledge that these questions have been mainly raised by a particular PR, namely this one.

I never got a response to my question about whether a patch to simply disable the feature on older OS versions would be accepted (after all there probably aren’t a lot of people who really need to use perf on them), so I was left wondering if all changes only benefiting those OS versions would be rejected.

1 Like